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INTRODUCTION 


This  is  the  final  report  on  a  six  month  research  and 
development  effort  into  Cost  Estimation  Methodology  for  Com¬ 
mand,  Control ,  Communications,  and  Intelligence  (C3I)  System 
Software.  The  objective  of  the  effort  was  to  define  and 
specify  an  estimating  concept  which  could  be  automated  for  use 
in  the  Conceptual  Phase  of  embedded  software  development.  The 
approach  developed  was  to  provide  improved  accuracy  while 
making  maximum  use  of  current  estimation  techniques  and  it  was 
to  be  both  user  friendly  and  interactive. 

During  proposal  preparation  the  software  cost  estima¬ 
tion  models  listed  in  table  1-1  were  reviewed,  and  it  was 
concluded  that  the  accuracy  of  each  depended  on  an  input 
estimate  of  the  expected  number  of  instructions.  Within  the 
models,  this  estimate  is  then  related  to  an  average  instruc¬ 
tion  productivity  rate.  In  most  cases,  productivity  rates 
were  developed  by  regressions  that  explained  variances  in 
terms  of  factors  related  to  programming  environment,  capabil¬ 
ities  of  the  software  analysts  and  progr ammmers,  requirements 
for  interfacing  with  other  programs,  machine  constraints,  and 
documentation  needs.  Since  the  different  models  are  regres¬ 
sions  of  different  sets  of  data,  their  basic  equations  require 
calibration  to  a  given  type  of  application  and  programming 
environment . 

The  most  recently  developed  model  reviewed  was  the  CQCOMO 


developed  by  Barry  Boehm  of  TRW,  Inc.  and  published  in  1981  by 


Table  1-1.  Software  Cost  Estimating  Models 


1.0  NAVAL  AIR  DEVELOPMENT  CENTER  Modal 

F.  Buck,  at  al."A  Cost-By-Function 
Modal  for  Avionics  Computer  Systems". 
NADC-SD-7088. 

Marcn  1971 


9.0  RCA  Modal 

F.  Freiman,  "PRICE  S  Software  Cost 
Estimating  Model", 

RCA  Price  Systems. 

1977 


2. 0  SDC  Model 

E.A.  Nelson.  T.  Fleishman.  "A  System 
for  Collecting  tc  Reporting  Costs  in 
Computer  Program  Development", 

System  Development  Corporation, 

TM— 341 1/000/00, 

11  April  1967 


10.0  ESD  Model 

S.A.  Bourdon.  J.A.  Duquette.  "A  Comput¬ 
erized  Model  far  Estimating  Software 
Life  Cycle  Costs  (Model  Concept)", 

USAF, 

April  1978 


C.E.  Walston,  C.P.  Felix,  "A  Method  of 
Programming  Measurement  and  Estimation", 
IBM  Systems  Journal,  Vol  16,  No.  1, 
pp.  54-73, 

1977 


4.0  GRC  Model 

E.N.  Dodson,  at  al.,  "Advanced  Cost 
Estimating  and  Synthesis  Techniques 
for  Avionics". 

General  Research  Corporation, 

Final  Report  CR-2-461, 

1975 


5.0  TRW  Models 

R.W.  Waiver ton,  "The  Cost  of  Developing 
Large  Scale  Software", 

TRW  Inc.,  IEEE  Transactions  on  Computer, 
Vol  C-23,  No.  6, 

June  1974 

(CQCOMO  Model) 

B.w.  Boehm,  Sgl£wgrg  Engineering 

Ssaggaisi, 

Prentice-Hall , 

1981 


o.v  TECOLOTE  (TEC)  Model 

f'c*J Fr»dmnick.  “A  Provisional  Model 
for  Estimating  Computer  Program 
Development  Costs". 

Tecolote  Research  Inc..  TM-7/Rev.  1. 
December  1974 


7.0  PUTNAM  (QSM)  Models 

L.H.  Putnam.  A.  Fitzsimmons.  "Slim, 
Software  Life  Cycle  Management 
Estimating  Model", 

0SN  Inc.. 

1978 


11.0  B0EIN8  (BCS)  Models 

R.K.E.  Black,  et  al.,  "BCS  Software 
Production  Data", 

Boeing  Computer  Services. 

March  1977 


12.0  SAMSO  (SAM)  Model 

D.L,  Hansen,  "Software  CER 
Feasibility  Study",  „ , 

Hq. ,  SAMSO.  Cost  Analysis  Division. 
December  1976 


13.0  Phister  Model 


M.  Phister,  Jr.,  PrgctUUia 

ItSDQOlBflX  «d  EEBDBBISI' 

Santa  Monica  Publishing  Company  U 
Digital  Press. 

December  1979 


14.0  MITRE  Model 

W.  Hahn  and  J.  Stone.  Jr..  "Software 
Transfer  Cost  Estimation  Technique”, 
MITRE,  H70-43, 

July  1970 


15.0  Schneider  Model 

V.  Schneider.  "Prediction  of  Software 
Effort  and  Project  Duration  — 

Four  New  Formulas", 

SI GPL AN  Notices.  Vol  13.  No.  6. 

June  1978 


16.0  JENSEN  Model 

R.W.  Jensen.  "An  Improved  Macrolevel 
Software  Development  Resource 
Estimation  Model". 

Procedures  of  ISPA  Conference, 

April  1985 

(Also  implemented  as  the  JS-1 
system  from  Computer  Electronics  Inc.) 


3.0  DCTY/RADC  Model 

J.H.  Herd,  et  al . ,  "Software  Cost 
Estimation  Study  I  t,  II.  Guidelines 
for  Improved  Software  Cost  Estimation" 
Doty  Associates  Inc..  RA0C-TR-77-22O. 
February  1977 


17.0  DSARC  Model 

B.C.  DeRoze.  "Embedded  Computer 
Resources  and  the  DSARC  Process 
A  Guidebook". 

Management  Steer ing  Committee. 
Embedded  Computer  Resources. 
OSD.  1977 
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Prentice-Hall,  Inc.  in  a  book  entitled  Software  Engineering 
1 

icgngmi.cs.  It  is  based  on  a  regression  analysis  of  63  data 
points  and  an  extensive  review  o-f  the  software  estimating 
methods  developed  to  date.  Because  it  incorporated  this  re¬ 
view  into  its  factors,  the  COCOMO  model  was  used  as  baseline 
for  this  study,  and  methods  for  programming  and  applying  it  as 
a  user  friendly  interactive  computer  program  compatible  with 
the  requirements  and  data  available  during  the  conceptual 
phase  were  researched.  Three  basic  software  sizing  methods 
were  reviewed  to  develop  an  approach  compatible  with  COCOMO: 
analogy,  computer  core  memory,  and  subjective  probability. 
The  available  data  to  support  the  proposed  approach  was  also 
researched  and  the  requirements  for  a  compatible  computer 
program  were  developed. 

This  report  presents  the  findings  of  the  research  and  the 
estimating  concepts  and  computer  program  development  recom¬ 
mended. 

Section  2  reports  the  research  into  methods  of  making  the 
COCOMO  model  user-f riendl y.  It  reviews  the  basic  models, 
their  inputs,  outputs,  and  assumptions,  and  reviews  an  inter¬ 
active  computer  adaptation  of  COCOMO  by  the  WANG  Software 
Institute  Graduate  School  (WICOMO)  . 

Section  3  reports  the  sizing  methodology  research  done. 
It  looks  at  analogous  software  sizing  methods  by  the  Aerospace 
and  Grumman  Corporations  and  the  default  library  analogous 

estimating  approach  developed  by  the  Navy  "HARDMAN"  pro- 

3,4,5 


ject 


It  reviews  Core  Memory  sizing  developed  by  Doty 


Associates,  subjective  probability  sizing  using  the  SLIM 

model,  and  it  touches  on  the  Software  Science  investigations 

6, 7, 8, 9,  10 

by  Halstead,  Elstoff,  and  McCabe. 

Section  4  reports  research  into  so-ftware  databases  and 
current  structures  being  used  by  the  Air  Force  Electronic 
Systems  Division  (ESD)  to  collect  C3I  data.  Specifically  re¬ 
searched  were  the  data  stored  in  DACS  (Data  and  Analysis  Center 
-for  Software)  at  RADC  and  the  Aerospace  Corporation  database, 

potential  ESD  project  data,  and  the  SARE  (Software  Acquisition 

11,12, 13, 14 

Resource  Expenditure)  data  collection  methodology. 

Section  5  presents  the  concepts  developed  for  a  user- 
friendly  software  design/life  cycle  cost  estimating  system.  It 
uses  the  C0CQM0  model  combined  with  sets  of  generic  software 
life  cycle  cost  baselines  called  up  and  modified  from  help 
screens  tied  to  estimating  equations.  It  presents  require¬ 
ments  for  an  interactive  computer  program  to  implement  the 
developed  methodology,  and  identifies  the  logic  and  functional 
modules  to  be  programmed. 

Section  6  presents  the  concepts  developed  for  an 
interactive  software  design/life  cycle  cost  estimating  system 
that  uses  the  C0C0M0  model  equations  and  libraries  of  generic 
software  C3I  baseline  structures  called-up  and  modified  with 
the  use  of  help  screens. 

Section  7  presents  the  concept  of  "Sizing"  libraries  and 
gives  an  example  as  to  how  existing  programs  could  be  analyzed 
to  develop  generic  C3I  software  breakdowns  and  hierarachy  of 
modules  of  instructions  that  could  form  the  basis  for  computer 
program  sizing. 


2.  MODEL  RESEARCH 


2. 1  COCOMO 

The  Constructive  COst  MOdel  <COCOM0)  is  a  software  devel¬ 
opment  and  maintenance  effort  estimating  model  that  exists  in 
a  hierarchy  of  three  increasingly  detailed  regressions  of  a 
database  of  63  software* proj ects  under  TRW  control.  Project 
data  was  grouped  into  development  mode,  application  type,  year 
of  development,  type  of  computer  used  for  development,  and 
programming  language.  Regressions  of  delivered  source  in¬ 
structions  (DSI)  against  manmonths  (MM)  of  development  effort 
were  made:  one  against  the  total  number  of  instructions  versus 
the  mode  of  development;  and  the  other,  the  number  of  instruc¬ 
tions  within  a  mode  of  development. 

2.1.1  Basic  Regressions 

Those  initial  data  base  regressions  resulted  in  a  set  of 
effort  estimating  equations  called  the  basic  COCOMO  model. 
Those  equations  are  the  following: 


Mode 

Effort 

1.05 

Organic 

MM  = 

2. 4 (KDSI) 

1 .  12 

Semi  detached 

MM  = 

3.0 (KDSI ) 

1.20 

Embedded 

MM  = 

3. 6 (KDSI ) 

They  estimate  the 

number  of 

manmonths  required 

to 

devel op 

a 

software  program 

of  a  given 

size  in  terms  of 

thousands 

of 

delivered  source 

instructions  (KDSI).  The  three 

modes 

of 

development  identified  in  the 

equations  are  as  follows: 

QC.9aruc  Mode  —  relatively  small  software  teams  in  a 
highly  familiar,  in-house  environment,  with  extensive 
experience  with  related  systems  within  the  organi 2 at i on, 
and  a  thorough  understanding  of  how  the  system  under 
development  will  contribute  to  the  organization’s  objec¬ 
tives.  Relatively  relaxed  about  the  way  the  software 
meets  its  requirements  and  interface  specifications. 
Generally  stable  development  environment,  with  very 
little  concurrent  development  of  associated  new  hardware 
and  operational  procedures,  minimal  need  for  innovative 
data  processing  architecture  or  algorithms,  relatively 
low  premium  on  early  completion  of  the  project,  and  no 
more  than  50  KDSI  of  new  software. 

Embedded  —  relatively  large  software  team  operating 
within  tight  constraints  to  develop  a  product  required  to 
operate  within  (is  embedded  in)  a  strongly  coupled  com¬ 
plex  of  hardware,  software,  regulations,  and  operational 
procedures.  A  small  team  of  analysts  is  used  in  the 
early  stages,  along  with  a  very  large  team  of  programmers 
to  perform  detail  design,  coding,  and  unit  testing  in 
parallel.  The  project  can  be  expected  to  expend  more 
effort  in  accommodating  changes  and  fixes;  and  higher 
costs  for  verification  and  validation  and  configuration 
management . 

Semidetached  Mode  —  an  intermediate  stage  between  the 
organic  and  embedded  modes.  Accordingly,  it  is  a  mixture 
of  the  organic  and  embedded  mode  char acter i st i c  in  which 
team  members  that  have  an  intermediate  level  of  experi- 


ence  with  related  systems,  with  a  wide  mixture  of  exper¬ 
ienced  and  inexperienced  members  that  have  experience 
related  to  some  aspects  of  the  systems  under  development, 
but  not  others.  The  product  size  ranges  between  50  and 
300  KDSI. 

The  basic  C0C0M0  model  also  had  regressions  against 
development  time.  The  results  of  those  regressions  are  the 
following  schedule  equations: 

Mode  Schedule 

0.38 


Organi c 

TDEV 

=  2. 5  (MM) 

0.35 

Semi  detached 

TDEV 

=  2.  5 (MM) 

0.  32 

Embedded 

TDEV 

=  2.5 (MM) 

The  primary  variable  in  these  equations  is  the  number  of 

* 

manmonths  estimated  using  the  effort  equations,  and  the  calen¬ 
dar  months  required  to  develop  the  software  (TDEV).  It  as¬ 
sumes  the  Rayleigh  distribution  function  for  the  determination 
of  full-time-equivalent  software  personnel  (FSP)  over  the 
development  phase: 

-<t2)/(2t?  ) 

FSP  =  MM(t/t*  ) e 


The  variable  t  represents  the  month  for  which  the  FSP  level  is 

being  calculated,  and  the  quantity,  t  ,  represents  the  month 

D 

at  which  the  project  achieves  its  peak  effort. 

2. 1.1.1  Adaptation  of  Software 

The  basic  C0C0M0  Model  estimates  the  development  effort 


and  schedule  time  tor  the  adaptation  of  existing  software  in 
terms  of  an  equivalent  number  of  new  delivered  source  instruc¬ 
tions  (EDSI),  which  is  used  in  the  place  of  DSI  in  the  COCOMO 
estimating  rel ati onshi ps.  The  equations  for  calculating  EDSI 
involve  an  intermediate  quantity,  the  adaptation  adjustment 
factor  (AAF) . 

EDSI  =  <ADSI) (AAF/100) 

where,  AAF  =  0.40 (DM)  +  0.30 (CM)  +  0.30(IM> 
and  ADSI  =  Adapted  DSI 

DM  =  Percent  design  modified 
CM  =  Percent  code  modified 
IM  =  Percent  of  integration  required  for 
modified  software 
* 

The  coefficients  in  the  AAF  were  determined  from  the  average 

fractions  of  effort  devoted  to  design,  code,  and  integration- 

and-test  in  the  COCOMO  data  base. 

2. 1.1.2  Software  Maintenance 

COCOMO  uses  an  estimated  Annual  Change  Traffic  (ACT) 

factor  to  estimate  annual  maintenance  manhours  (MM)  for  a 

AM 

software  program.  ACT  is  the  fraction  of  the  software’s 
source  instructions  expected  to  undergo  change  during  a  typi¬ 
cal  year,  either  through  addition  or  modification. 

(MM)  -  (1.0) (ACT) (MM) 

AM  DEV 

Another  alternate  factor  for  estimating  overall  life-cycle 

maintenance  manhours  (MM)  ,  from  acceptance  test  through 

M 


phaseout  is  the  maintenance/development  manhour  ratio  (M/D) . 


(MM)  =  (M/D) (MM) 

M  DEV 


A  third  alternative  is  an  estimate  of  the  thousands  of  source 

instructions  maintained  per  full-time  software  person,  and  the 

number  of  maintenance  personnel  (FSP)  required  to  support  a 

M 


given  size  development  (KDSI) 

DEV 


(MM)  =  12 (FSP) 

AM  M 

where, 

(FSP)  =  (KDSI) / (KDSI /FSP) 

M  M 

The  software  maintenance  data  in  the  COCOMO  data  base  reflect 
a  range  of  cards  per  person  (KDSI /FSP)  from  3.2  to  132  with  a 
median  of  25,  a  maintenance  productivity  (DSI/MM)  from  36  to 
1238  with  a  median  of  164,  and  an  Annual  Change  Traffic  (ACT) 
from  0.01  to  0.4  with  a  median  of  0.08. 

2. 1.1.3  Computer  Time 

COCOMO  adds  the  cost  of  computer  time  used  in  development 
of  software  and  the  cost  of  clerical  personnel  to  the  effort 
cost  estimates.  Computer  time  is  estimated  from  historical 
characteristics  of  projects  wherein  computer  hours  per  devel¬ 
opment  manmonth  have  been  determined  for  ma>:i,  midi,  and  mini 
type  computers.  Small  to  median  size  timeshared  developments 
used  0.2  to  1.5  hours  computer  time  per  development  manmonth; 
large  or  batch  application  developments  used  3  hours  per 
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manmonth;  and  real-time  developments  used  between  3  to  18 
hours  per  manmonth.  The  smaller  the  computer  used  the  larger 
the  number  of  hours. 

2. 1.1.4  Clerical  Effort 

Basic  COCOMO  estimates  cover  the  cost  of  professional 
personnel  and  par aprof essi onal s  such  as  program  librarians, 
but  not  clerical  effort.  Three  to  four  percent  of  the  basic 
manpower  estimate  must  be  added  to  cover  the  clerical  effort. 
2.1.2  Intermediate  Models 

COCOMO  regressions  are  further  refined  in  an  "intermedi¬ 
ate"  model  to  reflect  added  sets  of  cost  tiriver  attributes: 
o  Product  Attributes 

RELY  Required  Software  Reliabiltiy 
DATA  Data  Base  Size 
CPLX  Product  Complexity 
o  Computer  Attributes 

TIME  Execution  Time  Constraint 
STOR  Main  Storage  Constraint 
VIRT  Virtual  Machine  Volatility 
TURN  Computer  Turnaround  Time 
o  Personnel  Attributes 

ACAP  Analyst  Capability 
AEXP  Applications  Experience 
PCAP  Programmer  Capability 
VEXP  Virtual  Machine  Experience 
LEXP  Programming  Language  Experience 


o  Project  Attributes 


MODP  Modern  Programming  Practices 
TOOL  Use  of  Software  Tools 
SCED  Required  Development  Schedule 
The  intermediate  model  equations  are  as  follows: 


2®veloeCQ§!Qt  Mode 


Nominal  Effort  Eguation 


1.05 

Organic 

MM  * 

3. 2 (KDSI ) 

NOM 

1.  12 

Semidetached 

MM  = 

3.0 (KDSI) 

NOM 

1.20 

Embedded 

MM 

2. 8 (KDSI) 

NOM 

The  effort  multipliers  related  to  the  intermediate  model  are 
abstracted  in  table  2-1.  Except  for  SCED  (Required  Develop¬ 
ment  Schedule),  RELY  (Required  Software  Reliability),  and  MODP 
(Modern  Programming  Practices)  the  effort  multipliers  can  be 
applied  to  the  maintenance  effort  estimate  as  well  as  develop¬ 
ment.  SCED  is  only  a  factor  during  development,  not  main¬ 
tenance,  and  RELY  and  MODP  have  different  multipliers  for 
maintenance  effort  estimating.  The  same  computer  time  and 
clerical  effort  relationships  are  used. 


■.-'•VI 
>  \  -  -l 


'v  A  ’AV  -  \>\ 


v>K#v‘v  v :•  \  v v- 


Table  2-1.  Software  Development  Effort  Multipliers 


Cost  Driver 

Multiplier  Range 

Product  Attributes 

Lou 

Noainal 

High 

Required  softuare  reliability 

.75 

1.00 

1.40 

Data  base  size 

1.00 

1.16 

Product  coaplexity 

.70 

1.00 

1.65 

Computer  Attributes 

Execution  tiae  constraint 

1.00 

1.66 

Rain  storage  constraint 

1.00 

1.56 

Virtual  eachinc  volatility 

1.00 

1.30 

Conputer  turnaround  tiae 

1.00 

1.15 

Personnel  Attributes 

Analyst  capability 

1.4b 

1.00 

.71 

Applications  experience 

1.29 

1.00 

.82 

Progranoer  capability 

1.42 

1.00 

.70 

Virtual  nachine  experience 

1.21 

1.00 

Proqraaaing  language  experience 

1.14 

1.00 

Project  Attributes 

Use  of  aodern  progranoing  practices 

1.24 

1.00 

.82 

Use  of  softuare  tools 

1.24 

1.00 

.83 

Required  development  schedule 

1.23 

1.00 

1.10 

2.1.3  Detailed  Model 

\ 

The  final  codification  of  the  COCOMO  regressions  was  the 
development  of  separate  effort  multipliers  for  each  major 
development  phase.  These  multipliers  are  applied  at  a  three 
level  hierarchical  decomposition  of  the  software  product  whose 
cost  is  to  be  estimated.  The  lowest  level,  the  module  level 
effort  equations,  is  estimated  by  the  intermediate  model  equa¬ 
tion  cost  drivers  that  vary  at  the  lowest  level.  They  are: 
the  module’s  complexity  and  adaptation  from  existing  software, 
programmers’  capability  and  experience  with  the  language,  and 
the  virtual  machine  on  which  the  software  is  built.  The 
subsystem  level  effort  is  modified  by  the  remainder  of  the 
cost  drivers  (storage  constraint,  analysts  capability,  tools. 


schedule,  etc.)  which  tend  to  vary  from  subsystem  to  subsys- 


tem,  but  which  tend  to  be  the  same  -for  all  the  modules  within 
a  system. 

Two  work  sheets  are  provided  for  input  use,  CLEF  (Compo¬ 
nent  Level  Estimating  Form)  and  SHEF  (Software  Hierarchy  Esti— 

1 

mating  Form),  found  in  the  Prentice-Hall  book.  Table  2-2 
summarizes  the  similarities  and  differences  among  the  three 
levels  of  the  COCCMO  hierarchy  of  models  (Basic,  Intermediate, 
and  Detailed). 


1 

Table  2—2.  Summary  of  CQCQMO  Hierarchy  of  Models 


C0C0H0  Level 

Estimate 

Basic 

Intermediate 

Detailed 

Development 
effort  HNDEV 

mode,  KDSI 

mode,  KDSI, 

15  cost  drivers 

mode,  KDSI, 

15  cost  drivers  by  phase 

Development 

schedule 

mode.  NMDEV 

Same  a;  for  Basic 

Same  a;  for  Basic 

Maintenance 

effort 

HMOEV,  ACT) 

NHOEV,  ACT, 

15  cost  drivers  and 

2  maintenance  drivers 

Sane  a;  for  Intermediate 

Product  hierarchy 

Entire  system 

System/coaponents 

CLEF  form  and  pro¬ 
cedures 

System/ subsysten/aodul e 

SHEf  form  and  procedures 

Phase  distribution 
of  effort 

mode,  KDSI 

Same  a;  for  Basic 

node,  KDSI, 

IS  cost  drivers  by  phase 

Phase  distribu¬ 
tion  of  schedule 

mode,  KDSI 

Sane  a;  for  Basic 

Basic  schedule  distribution 
Detailed  effort  distribution 

Activity 

distribution 

mode,  KDSI 

Same  as  for  Basic 

Same  as  for  Basic 

Requirement; 

mode,  KDSI 

Sane  a;  for  Basic 

mode,  KDSI, 

phast  effort  15  cost  drivers  by  phase 

percentage 
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2.2  W I COMO 


WICOMO  (Wang  institute  Cost  Model)  is  the  Wang  Insti- 

2 

tute’s  computerized  implementation  of  the  COCOMO  model  .  It 
was  developed  in  the  Winter  1982  Project  I  course  at  the  Wang 
Institute  under  the  supervision  of  Dr.  James  P.  Bouhana. 

WICOMO  is  user  friendly  and  alleviates  much  of  the  prob¬ 
lem  of  having  so  many  inputs  needed  to  accomplish  an  estimate 
by  providing  a  default  baseline  and  definition  "help"  screens. 
It  generalizes  COCOMO’ s  system-subsystem-module  hierarchy  such 
that  it  can  be  extended  to  any  number  of  levels.  It  also 
generalizes  the  COCOMO  cost  driver  attributes  to  any  level  of 
the  software  hierarchy  defined.  Values  specified  at  higher 
levels  become  the  default  values  for  lower  level  components. 
Thus,  an  attribute  which  will  be  constant  for  the  entire 
system  need  be  specified  only  once  at  the  topmost  level  of  the 
hierarchy,  while  attributes  which  vary  at  the  lowest  level  can 
be  specified  for  each  such  component  individually. 

Cost  attribute  values  are  restricted  to  standard  rating 
levels.  Interpolation  can  be  accomplished  only  by  modifica¬ 
tion  of  the  effort  multiplier  tables.  However ,  these,  along 
with  all  other  numerical  values  associated  with  COCOMO,  are 
obtained  from  an  external  file.  This  allows  easy  calibration 
to  fit  the  experience  of  a  specific  organization.  The  inter¬ 
active  approach  used  is  illustrated  with  the  basic  WICOMO 
display  which  is  shown  in  figure  2-1.  It  contains  the  funda¬ 
mental  elements  of  the  COCOMO  effort  estimating  relationships 
and  an  identification  of  the  level  of  software  hierarchy  being 
estimated.  The  upper  part  of  the  screen  is  used  to  display  the 
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values  of  all  attributes  of  the  component.  The  lower  part  of 
the  screen  is  used  for  displaying  results  and  help  messages. 
The  bottom  two  lines  are  used  for  command  input  and  error 
messages  respectively. 

After  the  development  mode  and  estimated  number  of  deli¬ 
vered  source  instructions  are  entered,  an  estimate  of  develop¬ 
ment  cost  can  be  made.  Unless  an  estimate  for  each  attribute 
is  also  entered,  the  development  cost  estimate  made  would  be 
with  "nominal"  defaults  for  each  of  the  attributes.  Any  of 
the  attributes  can  be  changed  and  there  are  "help"  screen  to 
aid  in  their  estimation. 


Hierarchy 

Attributes 

Estimates 

Results 

Help  Messages 

Coeaand  Input 
It 

Error  Messages 

Figure  2-1.  WICOMG  Interactive  Screen  Format 

WICOMO  decomposes  software  systems  into  lower  levels  by 
estimating  source  instruction  counts  at  succeeding  lower 
levels.  Cost  driver  attributes  are  inherited  by  each  lower 


Current  Component:  Level 

• 

• 

Component  of: 

Rav: 

data: 

cpli: 

TIME: 

STOR: 

virt: 

turn: 

ACAP: 

AEXP: 

PCAP: 

VEIPs 

LEXP: 

hoop: 

tool: 

SCED: 

PDCOST: 

DDCOST: 

CUTCOST: 

ITCOST: 

dsi: 

NODE: 

...CoMand  'help'  to  find  out  ehat  coasands  are  available. 


Enter  a  couaand 
•> 
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level  and  instruction  counts  are  always  summed  to  the  higher 
level.  Changes  are  automatically  propagated. 

Three  basic  reports  are  available  from  WICOMO:  RESULTS, 

SUMMARY,  and  SCHEDULE.  The  "summary"  and  "schedule"  reports 
are  only  developed  at  the  system  level.  The  "schedule"  report 
presents  a  month-by-month  schedule  of  man  month  and  dollar 
expenditures. 

3.  SIZING  RESEARCH 

All  computer  program  sizing  is  based  on  some  type  of 
functional  decomposition  of  requirements.  Decomposition  starts 
early  in  a  development  and  continues  until  each  requirement  is 
decomposed  to  a  level  low  enough  to  be  allocated  to  hardware, 
software,  or  a  procedure.  Once  requirements  have  been  allo¬ 
cated  between  hardware  and  software,  software  modules  are 
identified,  named,  and  sized  in  source  lines  of  code. 

3.1  Analogous  Sizing 

In  analogous  sizing  instruction  countsfrom  similar  soft¬ 
ware  programs  developed  in  the  past  are  used  to  help  in  the 
actual  module  sizing  activity.  Research  was  conducted  into 
methodologies  for  implementing  analogous  sizing  in  a  user 
friendly  interactive  computer  program.  Three  activities  were 

investigated:  the  Aerospace  Corporation's  Guidlines, 

/ 

Grumman’s  Software  Cost  Estimating  Model,  and  the  Navy’s 
Hardman  Project  Life  Cycle  Cost  Model. 

3.1.1  Aerospace  Method 

The  Aerospace  method  does  analogous  sizing  methodology  in 
two  basic  steps.  First,  a  software  work  breakdown  structure 


is  developed,  then  instructions  -for  the  lowest  level  items  in 


the  breakdown  are  estimated  by  engineering  judgement.  The 
lowest  level  of  the  breakdown  is  to  the  -functional  level. 
Analogous  data  is  grouped  by  ranges  o-f  instruction  -for  differ¬ 
ent  types  of  functions.  Engineering  judgements  are  made  with 
respect  to  where,  in  the  range  of  instructions,  the  program  of 
interest  lies.  Judgements  are  made  based  on  three  considera¬ 
tions: 

Complexity  -  Items  to  consider  include  required  ac¬ 
curacy  or  precision  of  the  outputs,  the  amount  of 
autonomy  in  the  function,  and  the  survivablity  of  the 
application. 

0fi£i.i.£§tiQQ  ~  Consideration  of  the  sameness  of  the 
application  of  the  software  function  compared  with 
the  applications  in  the  database. 

icit£Q§i^£Qgss  -  The  extensiveness  of  the  require¬ 
ments  contained  in  the  function  to  be  estimated  is 
compared  with  thosfe  in  the  database  (i.e.,  the  number 
of  data  links,  the  number  of  secure  data  lines,  the 
number  and  types  of  interfaces,  etc..) 

3.1.2  Grumman  Method 

The  Grumman  approach  is  similar  to  Aerospace’s  except  it 
is  done  on  the  computer  in  a  cost  estimating  model  called 
’‘SOFCOST’’.  It  is  executed  as  an  interactive  computer  program 
in  which  the  estimator  is  coached  in  deriving  a  software  work 
breakdown  structure  (SWBS)  and  estimating  programs  size  by 
judgements  based  on  a  stored  database  of  historical  SWBS  size 
data. 
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The  estimator,  through  an  interactive  terminal  session, 
describes  the  system  requirements  such  that  a  SWBS  is  estab¬ 
lished  and  displayed.  The  highest  software  level  of  this 
structure  is  the  computer  program  conf i gurat i on  item.  The  next 
level  is  the  "category"  of  software  and  the  lowest  level  is 
the  function  within  a  category.  For  each  of  the  functions 
established  in  the  desired  work  breakdown  structure,  a  func¬ 
tional  size  data  base  is  searched.  After  viewing  the  dis¬ 
played  sizes  the  estimator  compares  this  output  with  his 
knowledge  of  the  functional  requirement  being  estimated.  A 
size  judgement  is  then  made  and  entered  into  the  model.  Fig¬ 
ure  3-1,  from  the  IEEE  paper,  shows  an  example  of  the  type  of 
display  of  size  information  given. 
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TACTICAL  PROGRAM  SIZE  DETERMINATION 
RESULTS  OF  DATA  SEARCH 

DATA  DESCRIPTOR:  CQHHUNICTN 


VEHICL 

MSN 

FUNCTION 

SUBFUNCTION 

SIZE 

(HRDS) 

HL 

A/C 

COMP 

HODL 

MANUF 

FIGHTR 

A-A 

COHMUNICTN 

DATA  LINK  CTL 

187 

20 

F14A 

CSDC 

TDY 

ELCTRN 

AEW 

communiCtn 

D/L  4  IN/OUT  CTL 

75 

32 

E2C 

L304F 

LITTN 

ELCTRN 

AEW 

COHMUNICTN 

D/L  4  IN/OUT  PROC 

1100 

32 

E2C 

L304F 

LITTN 

ELCTRN 

AEW 

COHMUNICTN 

D/L  4  AUTO  ASSOC 

180 

32 

E2C 

L3W 

LITTN 

ELCTRN 

AEW 

COHMUNICTN 

D/L  11  IN/OUT  INIT 

180 

32 

E2C 

L304F 

LITTN 

ELCTRN 

AEW 

COHMUNICTN 

D/L  11  IHIT  PROCESS  1200 

32 

E2C 

L304F 

LITTN 

ELCTRN 

AEH 

COHMUNICTN 

D/L  11  RCVE  PROCESS  2400 

32 

E2C 

L304F 

LITTN 

ELCTRN 

AEN 

COHMUNICTN 

DATA  LINK  4 

1500 

32 

E2C 

L304F 

LITTN 

ELCTRN 

AEH 

COHMUNICTN 

DATA  LINK  11 

4900 

32 

E2C 

L304F 

LITTN 

SPLPUR 

ASH 

COHMUNICTN 

NULL 

9500 

32 

E2C 

1832A 

UNIVC 

FIGHTR 

A-A 

COHMUNICTN 

DATA  LINK 

903 

24 

F14A 

54008 

CDC 

FIGHTR 

A-A 

COHMUNICTN 

DATA  LINK 

955 

24 

F14A 

54008 

CDC 

CARGO 

CR6 

COHHUNICTN 

SECURE  VOICE  CTL 

20 

l* 

YC14 

DAIS 

HSTNG 

CARGO 

CR6 

COHMUNICTN 

UHF  FRED  it  CHAN  SEL 

300 

16 

YC14 

DAIS 

HSTNG 

CARGO 

CR6 

COHMUNICTN 

VHF  FRED  &  CHAN  SEL 

470 

16 

YC14 

DAIS 

HSTN6 

CARGO 

CRG 

COHMUNICTN 

HF  FRED  7  CHAN  SEL 

300 

16 

YC14 

DAIS 

HSTNG 

IS  THERE  ENOUGH  INFORMATION  TO  MAKE  SIZE  JUDGEMENT? 
THE  ANSWER  IS  'YES’  OR  'NO’ 

'YES’ 


ENTER  SIZE  JUDGEMENT 


3.1.3  HARDMAN  Model 

The  Navy’s  HARDMAN  Project  Life  Cycle  Cost  Model  is  not  a 
software  cost  or  sizing  model,  but  its  spreadsheet  and  library 
features  are  worth  considering  for  analogous  estimating  adapt¬ 
ation  . 

The  estimating  system  consists  of  four  linked  programs 
that  combine  to  estimate  life  cycle  cost  of  equipments,  assem¬ 
blies,  and  subassemblies:  an  environment  data  set  program,  an 
equipment  design/cost  model,  a  Weapon  Removable  Assembly  (WRA) 
design/cost  model,  and  a  Shop  Removable  Assembly  (SRA) 
design/cost  model.  Each  model  is  similar  in  structure.  Each 
allows  manipulation  of  input  data  files  that  describe  the 
design  of  an  equipment,  assembly,  or  subassembly,  and  each 
computes  the  life  cycle  cost  of  a  proposed  design  at  its  as¬ 
signed  level.  In  each  case  when  a  data  set  is  created,  it 
becomes  part  of  a  permanent  data  library  stored  on  disk. 
Equipments  are  designed  by  entering  equipment-level  parameters 
and  choosing  from  the  library  of  stored  WRAs.  WRAs  are  de¬ 
signed  by  entering  WRA  level  parameters  and  choosing  from  the 
library  of  stored  SRAs.  The  SRA  is  the  generic  building 
bloc  k . 

The  Environment  Data  Set  program  requires  both  environ¬ 
mental  and  cost  factors  that  are  common  to  the  three  levels  of 
equipment  and  do  not  depend  on  the  type  of  equipment,  nor 
equipment  design.  These  data  are  common  input  to  the  other 
models.  Sets  of  these  data  can  be  stored  in  the  data  library 
and  designated  for  use  with  a  given  design. 


The  Equipment  Design/Cost  program  allows  the  creation  of 
a  library  of  alternate  equipment  designs  and  the  estimation  of 
the  life  cycle  cost  of  each  alternative.  The  WRA  Desiqn/Cost 
program  allows  the  creation  of  a  library  of  alternate  WRA 
designs  and  the  estimation  of  the  life  cycle  cost  of  each 
alternative.  The  SRA  Design/Cost  program  allows  the  creation 
of  a  library  of  SRA  designs  and  the  estimation  of  the  life 
cycle  cost  of  each  alternative.  Figure  3-2  illustrates  the 
information  displayed  from  the  library  for  an  equipment. 
Similar  displays  are  stored  for  WRAs  and  SRAs. 
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Equipment  Library  File 


3.2  Core  Requirements  Sizing 

Doty  Associates  developed  an  algorithm  -for  software  siz¬ 
ing  based  on  the  number  of  functions  to  be  programmed  and  the 
size  of  the  memory  of  the  computer  being  programmed.  The 
algorithm  was  developed  by  a  multivariate  regression  of  data 
obtained  from  a  study  by  the  John  Hopkins  University  Applied 
Physics  Laboratory.  That  algorithm  is  as  follows: 


0.337  0. 147  0.770  0. 177  +  k 

M  =  C  (N  )  (W  ) / (t  ) 3e 

F  S  C 


where, 


M  =  Memory  size  in  thousands  of  words  of  object 
code 

N  =  Number  of  major  functions  to  be  performed 
F 

by  the  software 

W  =  Word  size  in  bits 
S 


t  =  Cycle  time  of  processor  in  microseconds 
C 

K  =  A  constant  dependent  on  application 
where  K  equals: 

2.573  for  signal  processing 
2.727  for  missile  fire  control 
2.781  for  interfacing 
3.412  for  communication 
3.565  for  navigation 
4.046  for  command  and  control 
4.451  for  weapon  fire  control 
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k*l 


The  variable,  N  ,  is  defined  as  being  functions  such  as 
F 

communications,  target  tracking,  target  identification,  navi¬ 
gation,  system  monitoring,  display,  steering,  parameter  meas¬ 
urement,  tuning,  target  data  entry,  timing  sequence  control, 

etc..  W  and  t  are  defined  by  the  CPU  of  the  computer  system 
S  C 

planned  to  be  used.  By  assuming  that  average  core  utilization 
is  approx i matel y  BO  percent,  the  Doty  algorithm  can  be  used 
for  estimating  system  size.  In  order  to  do  this  a  HOL  code  to 
object  code  and  word  size  must  be  made.  A  summary  of  object 
code/source  instruction  expansion  ratios  are  given  in 
the  Boehm  book. 

3.3  PERT  Sizing 

The  SLIM  model  uses  what  has  come  to  be  known  as  the  PERT 
sizing  method  for  software  sizing.  According  to  a  paper 

presented  by  Dean,  the  SLIM  model  uses  its  EDITOR  model  to 
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determine  this.  It  requests  three  inputs: 

A,  the  smallest  possible  number  of  source  statements 
M,  the  most  likely  number  of  source  statements 

B,  the  largest  possible  number  of  source  statements. 
It  then  uses  each  of  these  inputs  to  get  an  expected  number  of 
lines  of  code  (E  )  by  using  the  formula 


E  =  (A  +  4M  +  B> /6 


It  computes  the  standard  deviation  of  each  input  by  the 
rel at i onshi p : 


a  =  (B  -  A) /6 
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The  probability  of  a  given  number  of  lines  of  code  is 
estimated  by  adding  and  subtracting  the  required  number  of 
standard  deviations. 

3.4  Software  Science 

In  1977  M.  H.  Halstead  published  a  theory  of  software 

8 

complexity  called  "Software  Science".  That  theory  contained 
a  measure  of  computer  program  size  in  terms  of  program  opera¬ 
tors  and  operands.  Operators  include  arithmetic  operators 
(e.g.,  +  ,  *,  /),  logical  operators  (e.g.,  greater  than, 

equal  to),  and  keywords  (e.g.,  FORTRAN  DO,  COBOL  PERFORM),  and 
del imi tors.  Operands  include  constants  and  variables. 


n  *  number  of  distinct  operators  in  program 
1 

n  =  number  of  distinct  operands  in  program 

n 

N  =  total  number  of  operators  in  program 
1 

N  ■  total  number  of  operands  in  program 

2 

The  length  of  a  program,  is  simply 


N  =  N  +  N 
1  2 

The  vocabulary,  n,  of  a  program  is  simply 


n  =  n  +  n 
1  2 

Elshoff  at  General  Motors  Research  Laboratories  calculat¬ 
ed  estimated  length,  N  as  follows 

N  =  n  log  n  +  n  1 og  n 
1  2  1  2  2  2 

In  addition,  Elshoff  found  that  the  estimated  length,  N  ,  more 

1 

closely  equated  the  actual  length,  N  ,  for  wel 1 -structured 


programs. 


There  have  been  studies  that  correlate  N  to  the  number  of 

source  instructions  required.  They  were  not  pursued  during 

this  contract;  however,  as  will  be  seen  later,  information  on 

operators  and  operands  are  available  in  the  NASA/SEL  database. 

Along  this  same  line,  McCabe  has  suggested  a  graph- 

theoretic  complexity  measure  of  computer  program  complexity 
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called  the  "cyclomatic  number".  For  structured  programs, 

cyclomatic  complexity  can  be  calculated  by  simply  counting  the 
number  of  compares: 

cyclomatic  complexity  =  compares  +  1 

Complexity  evaluation  is  applied  at  the  module  level  in  a 
program.  It  is  used  to  control  the  size  of  a  program  and  ''«• 
hence  its  under standabi 1 i ty  from  a  maintenance  standpoint. 

4.  DATA  RESEARCH 

A  search  was  made  of  the  type  of  data  that  would  be 
available  for  analogous  software  sizing  and  cost  model  verifi¬ 
cation  and  validation.  The  search  was  made  through  the  DACS, 
the  Data  and  Analysis  Center  for  Software,  operated  by  1IT 
Research  Institute  under  contract  to  RADC.  As  a  result,  an 
analysis  was  made  of  the  DACS  Software  Life-cycle  Emperical 
Database  <SLED) ,  the  Areospace  Corporati on ' s  Database,  and  the 
Electronics  Systems  Division  programs  on  which  machine  data 

was  collected  by  Doty  Associates  in  their  1980  sizing 
11,3,6 


studies 


4. 1  RADC  Data 


The  DACS  has  acquired  seven  sets  of  data  -from  various 
sources  and  maintains  this  data  in  the  Software  Life  Cycle 
Empirical  Database.  The  seven  sets  of  data  are  the  following: 

1)  The  DACS  Productivity  Dataset 

2)  The  Reliability  Dataset 

3)  The  NASA/SEL  Life  Cycle  Dataset 

4)  The  Verification  &  Validation  <V8<V>  Dataset 

5)  The  ARF  Error  Dataset 

6)  The  Baseline  Software  Dataset 

7)  The  Operations  and  Maintenance  <0&M)  Dataset 
Several  of  these  datasets  should  be  useful  to  analogous 
sizing. 

4.1.1  DACS  Productivity  Dataset 

This  dataset  consists  of  summary  data  on  roughly  400 
software  projects  and  was  compiled  by  Richard  Nelson  of  RADC. 
The  data  was  collected  from  open  literature  and  private 
sources  in  industry  and  government  and  represents  software 
development  projects  dating  from  the  early  1960's  through  the 
mid  1970’s.  The  software  applications  range  from  avionics  and 
space-flight  command  and  control  functions  and  radar  system 
support,  to  off-the-shelf  software  packages,  communications 
software,  and  management  information  systems.  Most  of  the 
projects  represent  DOD  or  other  government  applications. 

The  dataset  identifies  eight  parameters  and  several 
derived  factors  for  the  different  projects  it  contains; 
however,  not  all  parameters  are  available  on  each  project. 
The  eight  parameters  identified  are  the  following: 
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1)  Project  Identification 

2)  Project  Size 

3)  Project  Effort 

4)  Project  Duration 

5>  Source  Code  Language 

6)  Errors 

7)  Documentation 

5)  Implementation 

Project  size  is  the  number  of  lines  of  source  code. 
Source  lines  are  80  character  source  records  (assembly 
language)  provided  as  input  to  a  language  processor.  Where 
the  size  of  the  code  has  been  given  in  computer  words,  an 
arbitrary  conversion  to  DSLOC  was  made  dividing  the  computer 
words  by  two  for  high  order  language  DSLOC.  Errors  are  the 
number  of  formally  recorded  Software  Problem  Reports  (SPR) . 
Documentation  is  delivered  pages  of  documentation  including 
program  listings,  flow  charts,  operating  procedures,  mainten¬ 
ance  procedures,  and  other  descriptive  material.  Implementa¬ 
tion  is  the  techniques,  such  as  structured  coding,  top  down 
design  and  programming,  chief  programmer  teams,  code  reviews 
or  inspections,  and  librarian  or  program  support  library. 

The  derived  factors  are  the  following: 

1)  Productivity  (DSLOC/TMM) 

2)  Average  Number  of  Personnel  (TMM/TM) 

3)  Error  Rate  (ERRS/DSLOC) 

4)  Error  Rate  (temper al > (ERRS/TMM) 

5)  Documentation  Rate  (D0C/DSL0C) 
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4.1.2  Reliability  Dataset 

This  dataset  consists  of  software  failure  data  compiled 
by  John  Musa  of  Bell  Telephone  Labor ator i es.  The  data  was 
collected  throughout  the  mid  1970' s  and  represents  projects  of 
a  variety  of  applications  including  real  time  command  and 
control,  word  processing,  commercial  and  military.  For  each 
software  failure  in  the  dataset  the  following  items  are  re¬ 
car  ded : 

1)  Project  Identification 

2)  Failure  Number 

3)  Failure  Interval 

4)  Day  of  Failure 

4.1.3  NASA/SEL  Dataset 

The  NASA  Software  Engineering  Laboratory  (SEL)  at  Goddard 
Space  Flight  Center  collects  extensive  data  on  software  devel¬ 
oped  by  their  Systems  Development  Section.  Projects  repre¬ 
sented  in  the  dataset  span  the  functions  of  attitude  determin¬ 
ation,  attitude  control,  maneuver  planning,  orbit  adjustment, 
and  general  mission  analysis  support  systems.  The  data  is 
stored  in  eleven  files.  These  files  are  the  following: 

1)  Encoding  Dictionary  File 

2)  Estimated  Statistics  File 

3)  Header  File 

4)  Change  Report  File 

5)  Component  Status  Report  File 

6)  Component  Summary  File  -  part  1 

7)  Component  Summary  File  -  Part  2 

8)  Resource  Summary  File 
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9)  Run  Analysis  File 

10)  Component  Information  File 

11)  Growth  History  File. 

The  Encoding  Dictionary  file  defines  the  code  used  in  the 
other  files.  The  Estimated  Statistics  file  summarizes  actual , 
not  estimated,  size,  effort,  and  source  environment  data  on  a 
project.  The  Header  file  provides  schedule  dates  for  life 
cycle  milestones  of  the  project.  The  Change  Report  file 
records  effort  and  type  of  changes.  The  Component  Status 
Report  file  records  the  hours  spent  each  week  during  develop¬ 
ment  on  design,  code,  and  test.  The  Component  Summary  file 
summarizes,  for  each  component  of  the  program,  complexity, 
application,  size,  schedule,  effort  to  develop,  and  language. 
The  Resource  Summary  file  r^ftords  the  consumption  of  resources 
for  a  specified  time  period,  including  manpower,  computer,  and 
support  services.  The  Run  Analysis  file  records  the  objec¬ 
tives  and  results  of  each  computer  job  submitted  and  whether 
the  run  was  interactive  or  batch.  The  Component  Information 
file  provides  information  on  software  science  metrics,  and 
instruction  mix  parameters.  This  information  is  obtained  from 
"Source  Analyzer"  programs.  The  Growth  History  file  is  a 
weekly  accumulation  of  source  lines  written,  modules,  and 
changes. 

Of  particular  interest  in  the  NASA/SEL  Dataset  is  the 
•classification  of  components  as  combinations  of  the  following 
types  of  functional  software: 
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1)  I/O  Processing 

2)  Algorithmic 

3)  Logic  Control 

4)  System  Related 

5)  Data/COMMON  Blocks 
S)  Other 

and  the  following  software  module  details: 

1)  Number  of  Executable  Statements 

2)  Number  of  Lines  with  Comments 

3)  Number  of  Comment  Lines 

4)  Number  of  Unique  Operators 

5)  Number  of  Unique  Operands 

6)  Total  Number  of  Operators 

7)  Total  Number  of  Operands 

8)  Number  of  I/O  Variables  from  Module 

9)  Number  of  Decisions  (McCabe’s  Measure) 

10)  Number  of  FUNCTION  References 

11)  Number  of  I/O  Statements 

12)  Number  of  Assignment  Statements 

13)  Number  of  CALL  Statements 

14)  Number  of  FORMAT  Statements 
4.1.4  Verification  and  Validation  Dataset 

This  dataset  contains  data  collected  during  the  indepen¬ 
dent  verification  and  validation  (V&V)  of  five  software  pro¬ 
jects.  Although  the  specific  projects  are  not  identified  an 
overall  c 1 assi f i cat i on  is  made  as  to  whether  or  not  a  project 
is  C3I  or  not.  HOL  and  Assembly  language  lines  of  code  are 
given  and  the  programming  practices  used  identified.  The 
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primary  purpose  of  the  dataset  is  to  record  the  type  of  errors 
which  can  occur  during  V8<V  activities,  not  software  sizing. 
The  general  size  of  the  projects  reported  are  from  14,000  to 
52,000  lines  of  code. 

4.1.5  Operations  &  Maintenance  Dataset 

This  dataset  is  data  collected  against  the  PAVE  Phased 
Array  Warning  Systems  (PAWS).  The  PAVE  PAWS  is  an  over-the- 
horizon  radar  system  in  operation  at  Otis  Air  Force  Base  and 
Beale  Air  Force  Base.  The  data  collected  is  maintained  in 
seven  files: 

1)  Maintenance  Activity  File 

2)  CPCG  Description  File 

3)  CPCG  Status  File 

4)  Segment  Change  History  File 

5)  Change  History  File 

6)  Discrepancy  Rep'ort  History  File 

7)  Personnel  Experience  Profile 

The  Computer  Program  Conf i gurat i on  Group  (CPCG)  Description 
and  Status  files  may  be  of  use  in  sizing.  The  CPCG  is  a 
subgroup  of  computer  program  configuration  items.  The  CPCG 
Description  file  contains  data  providing  information  on  the 
character! sti cs  of  the  PAVE/PAWS  software  at  the  CPCG  level, 
including  size  in  source  lines  and  words  of  machine  code, 
environmental  factors,  and  development  constraints.  The  CPCG 
status  file  contains  information  on  the  size  of  the  CPCG  and 
its  revision  identification,  along  with  change  information. 
Much  of  the  information  in  the  file  is  compatible  with  the 
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the  COCQMO  model  requirements. 

4.2  Aerospace  Data 

The  Aerospace  Corporation  developed  a  software  siring 

.ji 

data  base  in  1983.  The  data  base  contains  data  concerning 
software  size  versus  software  function  at  the  subsystem  and 
component  level.  They  are  directly  used  in  analogous  sizing. 
Some  of  the  data  in  the  data  base  is  at  the  CF'CI  level,  some 
at  the  CPC  level,  and  still  others  at  the  module  level.  The 
data  includes  information  on  the  software  function,  the  size 
in  lines  of  code,  the  system,  the  type  of  application,  the 
development  status,  the  language  in  which  the  software  was 
written,  the  complexity  of  the  technical  requirements  of  that 
function,  the  computer  on  which  the  software  was  hosted,  and 
the  word  size  of  that  computer. 

A  five  level  software  work  breakdown  structure  is  used  to 
correlate  functions  to  applications,  to  environments,  to  plat¬ 
forms,  to  system.  An  example  of  the  software  work  breakdown 
structure  is  shown  in  figure  4-1.  The  application  level  is 
equivalent  to  a  CPCI,  the  function  level  is  equivalent  to  a 
CPC  or  a  module. 

The  data  base  contains  ranges  for  certain  software  func¬ 
tions.  These  ranges  were  based  on  engineering  judgement  as  to 
what  constituted  a  similar  function  and  what  requirements  were 
included.  Typical  standard  software  functions  isolated  in  the 
data  base  are  the  following: 

Attitude  determination  and  control 
Automatic  gain  control 


Attitude  maneuver 


Antenna  pointing 
Command  generation 
Command  guidance  system 
Command i ng 

Command  and  control  <C2) 

Command,  control  and  communications  <C3) 

Di agnostics 

Data  base  routine 

Data  reduction 

Display  management 

• 

Etc. 


Project  Naae  SYSTEM 

Flight  6round  PLATFORM 

Avionics  Unmanned  Manned  Naval  Fixed  Nobile  Rente  ENVIRONMENT 

Space  Space 

Spacecraft  Payload  Support  Mission  Data  Coeeand  t  Control  APPLlCATPv 

Planning  Reduction 

Attitude  Antenna  Utilities  Housekeeping  Teleeetry  Attitude  FUNCTION 

Hanuever  Printing  Processing  Determination 

Figure  4-1.  Software  Work  Breakdown  Structure  for  Aerospace  Data 
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4.3  ESD  Project  Data 
4.3.1  Projects 


The  addendum  to  the  ESD  "Handbook  of  Procedure  -for  Esti¬ 
mating  Computer  System  Sizing  and  Timing  Parameters"  contains 

the  types  of  data  that  can  be  used  in  the  development  of 
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computer  system  analogies  for  for  C3I  core  memory  sizing.  It 
contains  a  listing  of  typical  ESD  C3  major  projects,  and 
associated  listing  of  generalized  computer  equipment  specifi¬ 
cations  for  some  ESD  systems.  Typical  of  the  sample  projects 
identified  are  the  following: 

o  Air  Force  Satellite  Communications  System  1205 
o  Air  Force  World  Wide  Military  Command  and  Control 
System 

o  Cobra  Dane  633A 
o  Combat  Grande 

,  o  Combat  Theater  Communications  478T 

o  CONUS  Over-the-Hor i zon  Backscatter  Radar  414L 
a  E-3A  Airborne  Warning  and  Control  System  (AWACS)  41 1L 
o  E-4  Airborne  Command  Post  481B 
a  Joint  Surveillance  System  968H 

o  Joint  Tactical  Information  Distribution  System  634B 
o  NORAD  Cheyene  Mountain  Complex  Improvements  427M 
o  PAVE  PAWS  2054 

o  SAC  Digital  Information  Network  <SACDIN)  1136T 
o  Tactical  Air  Control  System  Improvements  (TACSI)  4856 
Typical  of  the  computer  equipment  specifications  identi¬ 
fied  are  the  following: 


o  Control  Data  Corporation  (CDC)  Cyber  74 

o  Control  Data  Corporation  <CDC)  Cyber  174-12 

o  Control  Data  Corporation  <CDC)  System  17 

o  Control  Data  Corporation  (CDC)  AN/UYK-25  MP60 

o  Data  General  NOVA  840 

o  Data  General  NOVA  1220 

o  Digital  Equipment  Corporation  (DEC)  PDF'  11/05 

o  Digital  Equipment  Corporation  (DEC)  PDF'  11/10  Cand 

11/403 

a  Honeywell  H-716 
o  Honeywel 1  H-6050  and  6060 
o  Honeywell  H-6080 
o  IBM  370/155 
a  Intel  80 
o  Raytheon  RDS-500 
o  Rolm  1603 

o  T e>;  as  Instruments  TI-980A 
o  UN I VAC  AN/UYK-7 
o  UN I VAC  AN/UYK— 20  (V-1600) 
a  UNIVAC  AN/UYK— 1 108 
o  UNIVAC  AN/UYK— 1 1 10 
o  UNIVAC  AN/UYK— 1616 

The  report  identities  the  primary  functions  and  characteris¬ 
tics  for  each  computer  used  by  each  system.  For  example,  it 
provides  detailed  information  on  the  following  computer 
characteristics: 
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Data  Format 


Main  Storage 

Central  Processor 

Input/Output  Control 

Peripheral  Equipment 

4.3.2  SARE  Data  Collection  Methodology 

The  Software  Acquisisiton  Resource  Expenditure  (SARE) 

data  collection  methodology  is  being  developed  by  the  MITRE 

Corporation  under  the  direction  of  the  Electronics  Systems 
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Division  (ESD)  of  the  Air  Force.  It  will  be  used  by  ESD  to 
collect  cost  (dollars  and  hours)  and  schedule  data  on  software 
developments  and  correlating  technical  characteri sti cs.  It 
establishes  sof tware-rel ated  Work  Breakdown  Structure  elements 
for  consistent  cost  data  collection  across  programs,  and  it 
provides  a  data  item  description  (DID)  for  software  cost  data 
collection  that  can  be  referenced  in  the  contract  data  re¬ 
quirements  list  (CDRL)  of  the  contract. 

A  draft  military  standard  provides  definitions  for  prime 
mission  software  decomposition: 

"Prime  mi.ssi.gn  software  Isoftware  sytem)..  The  aggregate 
of  all  computer  programs  and  databases  that  operate  as  part  of 
the  defense  system.  This  includes  applications  software 
developed  specifically  to  provide  a  prime  mission  function  of 
the  defense  systems  and  support  software,  such  as  off-the- 
shelf  operating  systems,  data  base  management  systems,  on-line 
diagnostics,  etc.,  which  execute  in  the  target  computer (s) 
during  any  mode  of  system  operation. ...  The  prime  mission  soft- 


ware  may  be  partitioned  directly  into  computer  program  con-fig¬ 
uration  items  or  it  may  be  partitioned  into  software  subsys¬ 
tems  which  are  in  turn  partitioned  into  computer  program 
conf iguratin  items... 

Software  subsystem.  A  subdivision  o-f  the  software  system 
which  operates  as  an  integral  whole  and  provides  a  major 
function  of  the  system.  A  software  subsystem  is  comprised  of 
two  or  more  computer  program  configuration  items... 

Computer  program  configuration  item  iQPC if .  An  aggregation  of 
software,  or  any  of  its  discrete  portions  which  satisfies  an 
end  use  function  and  has  been  designated  by  the  government  for 
configuration  management... 

Computer  program  component  fCRCf.  A  functionally  or  logically 

distinct  part  of  a  CPCI  distinguished  for  convenience  in 

designing  and  specifying  a  complex  CPCI  as  an  assembly  of 
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subordinate  elements..." 

Requirements  for  extended  CPCI  contract  work  breakdown 
structure  elements  were  given  in  the  draft  MIL-STD.  Figure 
4-2  illustrates  the  specified  breakdown  of  a  CPCI. 

The  draft  MIL-STD  is  used  in  conjunction  with  the  draft 
DID.  The  draft  DID  references  the  Boehm  book  Software  Engi.- 
neering  Economics,  and  the  "NASA/SEL  Data  Collection  Forms". 
This  makes  the  proposed  data  collection  compatible  with  the 
COCDMO  model.  There  are  Project  Summary  and  CPCI  Summary 
Forms  provided  with  the  DID.  The  Project  Summary  is  six  pages 
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Figure  4-2.  CPCI  Work  Breakdown  Structure  Elements 

and  encompasses  the  -Following  eleven  areas: 
o  Project  Description 
o  Resources 
o  Total  System  Size 
o  Difficulty 
o  Techniques  Employed 
o  Formalisms  Used 
o  Automated  Tools  Used 
o  Software  Standards 
o  Project  Schedule 

o  System-level  Software-Related  Documentation 
o  Corporate  Experience 


1.  SIZE 


3.1  OELIVOASLE  SOUtCE  INSTRUCTIONS  EXCLUDING  SOURCE  COSE  DOCUWNTATION :  _  INSTRUCTIONS 
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3.5  DATABASE  SIZE:  BYTES 
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Figure  4-3.  CPCI  Summary  Form  (cont.) 
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4.2  PRECISION  or  SPECIPICATION: 


a.  vat  precise  _  ».  precise  _  c.  imprecise  _ 

3.  INTERFACES 

3.1  MUMSER  Or  COMPONENTS  CALLED:  _  HAKES ;  _ _ __ 


3.2  MUMS  El  CALC  INC  HIS  CPCX:  _  HAMS: 


5.J  nuns  a  or  oirmon  i/o  formats;  imr _ ovmrr 


6. 

6.1 


DIFFICULT? 

PERCENT  UTILIZATION 


<  5 OX  31Z  TO  7 OX  711  TO  SSI  86Z  TO  951 


A.  MAIN  STORAGE 
S.  PERIPHERAL  STOIACC 

C.  EXECUTION  TIKE 


6.2  SECURITY :  DOES  A  00 D  SECOBXTT  CLASSIPICATXOM  APTLY  TO  THE  CTCX  Ot  AMY  OP  ITS  INPUTS /OUTPUTS 

6.2  PROTECTION:  IS  Til  CTCX  REQUIRED  TO  SATISFY  AMY  PRIVACY  Ot  PROTECTION  REQUIREMENTS?  _ 

6.4  MULTIPLE  SITE  CONPICURATION  : 

A.  NUNS Q  OP  OISTINCT  SITES 

•  .  m ma  or  oistxct  compicoiatioms  _ _  _ 


6.5  REQUIRED  CPCI  RCLIASXLITT  <CN«CE  dmOftUTt  UXZL)  : 

A.  VERY  LOW  _ 

».  LOW  _ 

C.  NOMINAL  _ 

D.  HIGH  _____ 

E.  VERY  HICK  _ 

6.6  COMPLEXITY  (CHECH  THE  APPROPRIATE  LEVEL): 

A.  VERY  LOW  _ 

S.  LOW  _ 

C .  NOMINAL  _ 

0.  HIGH  _ 

E.  VERY  MICH  _ 


] 

Figure  4-3.  CPCI  Summary  Form  (cont.) 


E.  VCIY  HICH 


A  table  of  generic  operational  and  support  functions  is 


provided  for  uniformity  of  data  cl assi f ication.  That  table  is 
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shown  in  Table  4-1. 


Table  4-1.  Software  Functions 


Type 

Category 

Index 

Function 

Operational 

Displays 

t.1 

Avionics 

1.2 

Command,  Control,  &  Communications 

1.3 

Other 

Avionics 

2.1 

Mission  Planning 

2.2 

Navigation 

2.3 

Aircraft  Steering  &  Flight  Control 

2.4 

Sighting,  Designation  &  Location  Determination 

2.5 

Weapon  Delivery 
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Electronic  Countermeasures 

Z7 

Other 

Command. 

3.1 

Network  Monitoring 

Control.  A 

12 

Network  Control  &  Switching 

Communication 

3.3 

Sensor  Control 

14 

Signal  Processing 

15 

Message  Processing 

18 

Message  Distribution 

3.7 

Message  Logging  &  Retrieval 

3J 

Data  Reduction 

19 

Other 

Executive 

4.1 

Computer  Resource  Management 

4.2 

Computer  Operator  Interface 

4.3 

Other  Terminal  Operator  Interface 

4.4 

Special  Oevice  Interface 

4.5 

Other  Input  or  Output 

4.6 

Error  Handling/Reconfiguration/Recovery 

4.7 

Multicomputer  Configuration  Control 

4.8 

Performance  Monitoring  Si  Data  Collection 

4.9 

Other 

Data  Bast 

5.1 

On-Line  Data  Base  Retrieval  &  Output 

5.2 

On-Line  Data  Base  Initialisation  Si  Updating 

5.3 

Other 

Training 

6.1 

Control  of  Exercise  Sequencing 

8.2 

Operator  Performance  Oats  Collection 

8.3 

Other 

On-Line 

7,1 

System  Readiness  Test 

Eauipmant 

7.2 

Computer  Diagnostic 

Diagnostic 

7.3 

Memory  Diagnostic 

• 

7.4 

Oisptav  Diagnostic 

7.5 

Switch/Indicator  Panel  Diagnostic 

7.6 

I/O  Diagnostic 

7.7 

Mode  Diagnostic 

7.8 

Other 
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Table  4-1.  Software  Functions  (cont.) 


Computer  Resource  Management 
Computer  Operator  Interface 
Terminal  Operator  Interface 
Input  or  Output 

Error  Handling/Reconfiguration/Recovery 
Performance  Monitoring  &  Data  Collection 
Other 

Off-Line  Computer  Diagnostics 
Other 

Higher-Order  Language  Compiler 

Assembler 

Debugger 

Loader  or  Editor 

Other 

Data  Base  Definition 

Data  Base  Initialization  or  Updating 

Oata  Base  Retrieval  &  Output  Formatting 

Data  Base  Restructuring 

Off-Line  Oata  Base 

Other 

Oata  Base  Design 

Oata  Basa  Processor  Design 

Performance  Simulation 

Oata  Reduction 

Oata  Analysis 

Other 

Test  Case  Generation 
Test  Case  Oats  Recording 
Test  Oata  Reduction 
Test  Analysis 
Other 

Madia  Conversions 
Format  Translation 
Sort/Merge 

Program  Library  Maintenance 
Other 

Oata  Reduction 
Training  Analysis 
Scenario  Preparation 
Other 

Project  Event  Status  Accounting 
Schedule  Maintenance/Proiection 
Financial  Accounting 
Software  Cost  Reporting 
Hardware  Cost  Reporting 
Software  Cost  Prediction 
Hardware  Cost  Prediction 
Other 

Interfacing  Hardware  Simulations 
Environmental  Simulsttons 
Operator  Action  Simulations 
Other 


5.  CONCEPT  DEVELOPMENT 


From  each  area  researched  selected  features  were  inte¬ 
grated  into  a  concept  for  an  interactive  software  cost  estima¬ 
ting  model  compatible  with  the  amount  of  information  available 
at  the  conceptual  phase  of  the  life  cycle.  Figure  5-1  illus¬ 
trates  the  features  selected. 

5.1  Selected  Features 

The  heart  of  the  concept  is  the  COCOMQ  software  cost 
estimating  equations.  These  equations  are  input  by  analogous 
judgments  made  from  reviews  of  stored  libraries  of  baseline 
C3I  system  software.  The  database  structure  used  is  a  combin¬ 
ation  of  the  data  structures  used  by  the  SARE  breakdown  devel¬ 
oped  by  MITRE  and  the  formats  of  the  DACS  center.  The  WICOMO 
"help"  screen  approach  is  the  bases  for  parameter  inputting, 
and  the  Navy  HARDMAN  concept  of  default  libraries  will  be  th- 
basis  for  sizing  analogies  and  CQCOMO  calibration.  Finally, 
there  will  be  compatibility  with  the  NASA/SEL  dataset  generic 
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Figure  5-1.  Concepts  Selected 
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module  structure  and  the  metrics  of  software  science  and 


cyclomat i cs. 

5.2  Dataset  Formats 

Software  design  trade-off  data  set  formats  were  formu¬ 
lated  along  the  basis  of  those  used  for  hardware  in  the  Hard¬ 
ware  models.  These  are  the  sets  of  data  that  are  compatible 
with  a  cost  estimate  made  using  the  COCOMO  model.  Three 
levels  of  software  breakdown  were  formulated:  modules,  CF'Cs, 
and  CF'CIs.  A  module  is  defined  to  be  compatible  with  the  SARE 
as  a  discrete  part  of  a  computer  program  configuration  item 
(CPCI)  with  an  identifiable  function  and  which  can  be  indivi¬ 
dually  compiled  or  assembled. 

Modules  are  grouped  into  six  generic  classes  to  serve  as 

building  blocks  of  software  code  from  which  CF'Cs  and  CF'CIs  can 

► 

be  designed.  These  six  classes  are  compatible  with  those 
identified  by  the  NASA  Software  Engineering  Laboratory: 

1)  System  Related 

2)  Input /Output  Processing 

3)  Algorithmic 

4)  Logic  Control 

5)  Data /COMMON  Block 

6)  Other 

A  generic  "system  related"  module  is  defined  as  a  logical 
block  of  code  used  for  operating  systems,  executive  programs, 
and  task  management  programs.  " Input/Output  Processing"  mod¬ 
ules  are  logical  blocks  of  code  related  to  activities  external 
to  the  computation  system.  "Algorithmic"  modules  are  logical 
blocks  of  code  used  for  calculations  of  formulas,  equations, 
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tr i gonometry ,  and  data  manipulation  in  general.  "Logic  Con¬ 
trol"  modules  are  logical  blocks  o-f  code  used  for  making 
decisions  based  on  previously  stored/manipulated  data. 
"Data/COMMON  Block"  modules  are  blocks  of  instructions  related 
to  those  constants,  either  volatile  or  nonvolatile,  which  are 
set  by  the  programmer.  Figure  5-2  shows  the  structure  of  the 
Module  level  dataset  format.. 

A  computer  program  component  (CPC)  is  a  grouping  of 
software  modules  into  logically  distinct  parts  of  a  CF'CI 
distinguished  for  convenience  in  design  and  speci f i cat i on . 
Figure  5-3  shows  the  structure  of  the  CPC  level  dataset  format. 

Figure  5-4  shows  the  structure  of  the  CPCI  level  report. 

A  CPCI  is  an  aggregation  of  software  computer  program 
components  which  satisfies  an  end  use  function  and *has  been 
designated  for  conf i gurati on  management. 

Figures  5-2,  5-3,  and  5-4  are  the  input  and  output  infor¬ 
mation  that  will  be  programmed  to  appear  on  the  display  soft¬ 
ware  cost  estimating  workstation  terminal  and  be  printed  out 
in  hardcopy.  The  acronyms  in  bold  print  define  the  input  data 
"help"  screens  that  will  be  programmed  and  called  by  typing 
that  acronym.  Any  input  will  be  changable  and  the  resulting 
changes  will  automati cal  1 y  be  made  in  the  associated  software 
life  cycle  cost  estimate. 

The  output  of  the  estimate  is  a  software  life  cycle  cost 
and  its  associated  estimating  parameters.  Software  life  cycle 
costs  are  defined  as  consisting  of  Development,  Implementation, 
and  Maintenance  costs.  The  elements  of  development  cost  are 


Plans  and  Requirement  costs.  Product  Design  costs.  Programming 
costs,  Integration  and  Test  cost,  and  the  cost  of  computer 
time  used  in  program  development  .and  test.  Implementation 
costs  are  the  costs  of  computer  program  installation  and 
operator  training.  Maintenance  costs  are  the  costs  of  compu¬ 
ter  program  update  and  repair  (debugging).  The  parameter 
summary  gives  the  basis  for  the  life  cycle  cost  estimate 
resulting  from  using  the  inputs  in  the  COCOMO  model  equations. 
KEDSI  is  thousands  of  "equivalent"  delivered  source  instruc¬ 
tions.  Development  MM  are  the  total  person  months  required 
for  development.  Annual  Maintenance  MM  are  the  total  person 
months  required  annually  for  computer  program  maintenance. 
The  Nominal  Development  and  Implementation  times  are  the  cal¬ 
endar  months  required  for  those  functions.  At  the  CPC  level 
the  modules  in  the  CPC  are  tabulated  along  with  their  KEDSI 
and  development  and  annual  maintenance  person  months.  Similar¬ 
ly  at  the  CF'CI  level  the  CPC  within  a  CF’CI  are  tabulated. 
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Software  Module 

****-IH***********************#************************-**************** 


Function : 


COST  SUMMARY  <  YR  *000) 

******■*•*#•**•■*•*•*•**•  *■**#■*■*■*■#■•*■*•*  #■*■*•*■#■ 

LIFE  CYCLE  COST 


DEVELOPMENT  COST 


Plans  and  Requirement 
Product  Design 
Pr ogrammi ng 
Integration  and  Test 
Computer  Time 

IMPLEMENTATION  COSTS 


Instal 1 ati on 
Training 


PARAMETER  SUMMARY 

KEDSI 

Development  MM  _ 

Computer  Time  _ 

Annual  Maintenance  MM  _ 

Nominal  Development  Time  _ M 

Nominal  Implementation  Time  _ M 

Length  of  Operating  Life  _ YR 


MAINTENANCE  COSTS 


Update 

Repair 


INPUT  DATA 

*•*■*■*-**■*•*•*■*  ^N> 

1  DEVC  Development  Computer  Type  (MAXI . MIDI , MINI , MICR) .  .  . 

2  MODE  Software  Development  Mode  (QRGN, SEMI , EMED)  . 

3  KDSI  Thousands  of  Delivered  Source  Instructions (decimal ) . 

4  ADPT  Percent  KDSI  Adapted  (integer)  . 

5  CPI  Conversion  Planning  Increment  (integer) . 

6  DM  Percent  Design  Modified  (integer) . 

7  CM  Percent  Code  Modified  (integer) . 

3  IM  Percent  Integration  Required  for  Mod.  (integer).  .  . 

9  COMP  Computer  hrs/mm  of  Development  (decimal)  ...... 

10  CPLX  Module  Complexity  (decimal).  ......  . 

11  RELY  Required  Module  Reliability  (decimal).  .  .  . 

12  PCAP  Programmer  Capability  (decimal).  ...  . 

13  VEXP  Virtual  Machine  Experience  (decimal)  . 

14  LEXP  Programming  Language  Experience  (decimal) . 

15  AEXP  Applications  Experience  (decimal).  .  .  . 

16  INST  Installation  Complexity  (decimal).  ....  . 

17  TRAIN  Training  Complexity  (decimal) . 

18  ACT  Annual  Change  Traffic  (decimal) . .  .  .  . 


Figure  5-2  Computer  Program  Module  Dataset 
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Software  CPC 

********************************************************************* 
Function : 


COST  SUMMARY  (  YR  *000) 

*********■#■■#•  ■*•*■•*•*•***#•■»■■*•■*•**■#■■#•***■*■■** 


LIFE  CYCLE  COST 


DEVELOPMENT  COST 


Plans  and  Requirement 
Product  Design 
Programmi ng 
Integration  and  Test 
Computer  Time 

IMPLEMENTATION  COSTS  TOTAL 


Instal lation 
Training 


MAINTENANCE  COSTS 


Update  _ 

Repair  _ 

INPUT  DATA 
*«"**"**#*** 

1  DEVC  Development  Computer  Type  (MAX I , MIDI , MINI , MICR)  .  .  . 

2  MODE  Software  Development  Mode  (ORQN, SEMI , EMED)  . 

3  KDSI  Thousands  of  Delivered  Source  Instructi ons (deci mal ) . 

4  ADPT  Percent  KDSI  Adapted  (integer)  .  .  . 

5  CPI  Conversion  Planning  Increment  (integer) . 

6  DM  Percent  Design  Modified  (integer) . 

7  CM  Percent  Code  Modified  (integer).  .  . 

S  IM  Percent  Integration  Required  for  Mod.  (integer).  .  . 

9  COMP  Computer  hrs/mm  of  Development  (decimal)  . 

10  CPLX  Module  Complexity  (decimal) . 

11  RELY  Required  Module  Reliability  (decimal) . 

12  TIME  Execution  Time  Constraint  (decimal) . 

13  STOR  Main  Storage  Constraint  (decimal) . 

14  DATA  Data  Base  Size  Factor  (decimal) . 

15  ACT  Annual  Change  Traffic  (decimal) . .  .  .  . 


Nominal  Development  Time  _ M 

-^Nominal  Implementation  Time _ M 

Length  of  Operating  Life  _ Y 


PARAMETER  SUMMARY 

********************************** 
MODULE  QTY  KEDSI  MM  MM 

DEV  AM 

System . _  _  _  _ 

I/O  _  II _  _  _ 

Algor.  _  _  _  _ 

Logic  _  _  _  _ 

D/B 

Other 


Figure  5-3  Computer  Program  Component  Dataset 


Software  CPC I 

********************************************************************* 


Function: 


COST  SUMMARY  (  YR  *000) 

******************************** 


LIFE  CYCLE  COST 


DEVELOPMENT  COST 


Plans  and  Requirement 
Product  Design 
Pr ogrammi ng 
Integration  and  Test 
Computer  Time 

IMPLEMENTATION  COSTS 


Instal 1 ati on 
Training 


PARAMETER  SUMMARY 

********************************** 
CPC  QTY  KEDSI  MM  MM 

DEV  AM 


TOTAL 


Nominal  Development  Time 
Nominal  Implementation  Time 
Length  of  Operating  Life  _ YR 


MAINTENANCE  COStS* 


Update 

Repair 


INPUT  DATA 
********** 


1 

DEVC 

2 

MODE 

KDSI 

4 

ADPT 

5 

CPI 

6 

DM 

7 

CM 

8 

IM 

9 

COMP 

10 

CPLX 

1 1 

RELY 

12 

VIRT 

13  TURN 

14  ACAP 

15  MODP 

16  TOOL 

17  ACT 
IS  YEAR 


Development  Computer  Type  (MAX  I , MIDI , MINI , MICR) .  .  . 

Software  Development  Mode  (ORGN, SEMI , EMED)  . 

Thousands  of  Delivered  Source  Instructions (decimal ) . 

Percent  KDSI  Adapted  (integer)  ......  . 

Conversion  Planning  Increment  (integer) . 

Percent  Design  Modified  (integer).  ...  . 

Percent  Code  Modified  (integer) . 

Percent  Integration  Required  for  Mod.  (integer).  .  . 

Computer  hrs/mm  of  Development  (decimal)  . 

Module  Complexity  (decimal) . 

Required  Module  Reliability  (decimal) . 

Virtual  Machine  Volatility  (decimal)  .  . 

Computer  Turnaround  Time  (decimal)  . 

Analyst  Capability  (decimal)  . 

Use  of  Modern  Programmming  Practices  (decimal)  .  .  . 

Use  of  Software  Tools  (decimal).  .  . 

Annual  Change  Traffic  (decimal).  .  .  . 

Dollars  (then,  now) . . . 


Figure  5-4  Computer  Program  Configuration  Item  Dataset 
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3  3 


5.3  Dataset  Inputs 


The  inputs  at  each  level  of  the  software  hierarchy  con¬ 
tain  both  common  and  unique  data.  The  following  common  inputs 
are  required  regardless  of  the  software  structure  level  being 
estimated: 

DEVC  —  the  expected  development  computer  (maxi,  midi, 
mini ,  micro) 

MODE  —  the  expected  software  development  mode  as  defined 
by  Boehm  (organic,  semidetached,  and  embedded) 

KDSI  —  the  estimated  number  of  thousands  of  delivered 
source  instructions. 

ADPI  —  the  estimated  percent  of  KDSI  that  could  be 
adapted  from  existing  programs. 

CPI  —  the  estimated  planning  increment  of  instructions 
needed  to  do  the  conversion  analysis  and  planning. 

DM  —  the  estimated  percent  of  existing  programs  that 
would  be  redesigned  to  perform  the  required  func¬ 
tions  and/or  missions. 

CM  —  the  estimated  percent  of  existing  code  required 
to  be  modified. 

IM  —  the  estimated  percent  of  normal  integration 
required  for  adapted  software  integration. 

COMP  —  the  estimated  computer  run  time  hours  required  to 
support  a  person— month  of  software  development 
activity  based  on  a  type  of  computer  and  soft¬ 
ware  product. 

CPLX  —  the  estimated  relative  effort  multiplier  based  on 
complexity  of  the  software  program  to  be  devel¬ 
oped  for  the  number  of  delivered  source  instruc¬ 
tions. 

RELY  —  the  estimated  relative  effort  of  software  develop¬ 
ment  required  for  software  reliability  for  a 
given  number  of  delivered  source  instructions. 

ACT  —  the  estimated  annual  percent  of  effort  required 
for  software  program  source  instruction  change 
through  additions  or  modifications. 


At  the  module,  but  not  the  CPC  and  CPC  I  levels,  the  fol¬ 
lowing  information  is  input: 


PCAP  —  the  estimated  relative  software  production  based 
on  programmer  capability. 

VEXP  —  the  estimated  relative  software  production  based 
on  programmer  virtual  machine  experience. 

LEXP  —  the  estimated  relative  software  production  based 
on  the  level  of  programming  language  experience 
of  the  project  team  developing  the  software  module. 

AEXP  —  the  estimated  relative  software  production  based 
on  programmer  experience  with  the  software  appli¬ 
cation. 

INST  —  the  estimated  percent  of  development  effort 

required  for  software  program  installation  and 
checkout . 

TRAIN  -  the  estimated  percent  of  development  effort 

required  for  software  operator  and  maintenance 
support  training. 


At  the  CPC  but  not  the  CPCI  or  module  levels,  the  following 
unique  information  is  input: 


TIME  —  the  estimated  added  effort  required  for  a  given 
number  of  instructions  based  on  expected  available 
execution  time. 

STQR  —  the  estimated  added  effort  required  for  a  given 
number  of  instructions  based  on  program  expected 
main  storage  usage. 

DATA  —  the  estimated  relative  effort  for  the  development 
of  the  size  of  the  data  base  required. 


At  the  CPCI  but  not  the  CPC  or  module  levels,  the  fallowing 
unique  information  is  input: 


VIRT  —  the  estimated  virtual  machine  volatility  impact 
on  the  effort  required  to  develop  a  given  number 
of  delivered  source  instructions. 
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TURN 


—  the  estimated  computer  turn-around  time  -for 
program  decks  effect  on  the  effort  required  to 
develop  a  given  number  of  delivered  source  in¬ 
structions,. 

ACAP  —  the  estimated  impact  of  the  software  analysts 
capability  on  the  effort  required  to  develop  a 
given  number  of  delivered  source  instructions. 

MODP  —  the  estimated  impact  of  the  amount  of  modern 
programming  methods  applied  to  the  development  on 
the  effort  required  to  develop  a  given  number  of 
delivered  source  instructions. 

TOOL  —  the  estimated  impact  of  the  presupposed  software? 

tools  that  will  be  used  on  the  effort  required  to 
develop  a  given  number  of  delivered  source  in¬ 
struct  i  ons. 


The  programs  that  generate  the  datasets  reports  will  be 
capable  of  running  independently  or  additively,  i.e.,  a  run 
can  be  made  at  the  CPCI  level  by  inputting  the  CPCI  level 
model,  at  the  CPC  level  by  inputting  the  CPC  level  model,  or 
at  the  module  level  by  inputting  the  module  level  model;  or  a 
run  could  be  made  of  CPCs  built  from  groups  of  modules,  and 
CF'CIs  from  groups  of  CPCs.  At  each  level  of  the  software 
breakdown  Help  screens  have  been  developed  to  aid  inputting, 
and  at  each  level  default  data  will  be  developed  for  all 
inputs.  Default  data  will  be  contained  in  libraries  of  mod¬ 
ules,  CPCs,  and  CPCI  life  cycle  cost  data  sets. 

5.4  Cost  Estimating  Equations 

The  equations  to  be  used  to  calculate  estimates  of  life 
cycle  cost  are  the  equations  of  the  COCOMO  model  with 
modifications  to  be  compatible  with  the  three-tiered  software 
structure  and  an  interactive  computer  program: 
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THOUSANDS  EQUIVALENT  DELIVERED  SOURCE  INSTRUCTIONS  (KEDSI) 


NODULE  KEDSI  =  C < ADR I / 100)  (KDSI ) 3 C 1 . O  +  ( 0 . 40  ( DM  >  +  0.30 (CM) 

+  O . 30 ( I M )  +  CPI)/ 1003 
CPC  KEDSI  =  KEDSI 

MODULES 

CPC  I  KEDSI  =  KEDSI 

CPC 


ORGANIC  MM 

NOM 

SEMIDETACHED  MM 

NOM 

EMBEDDED  MM 

NOM 

MM 

DEV 


PERSON  MONTHS  (MM) 
1 . 05 

3. 2 < KEDSI) 

1.  12 

3.0 (KEDSI 

1 . 20 

2. S (KEDSI) 


CMM  3  C EAF 3 
NOM 


DEVELOPMENT  EFFORT  ADJUSTMENT  FACTOR  (EAF) 


MODULE  EAF 
CPC  EAF 
CPC  I  EAF 


C ( PCAP ) (VEXP) (LEXP) (CPLX ) (RELY) (AEXP) 3 
C (TIME) (STOR) (DATA) 3 
C (VIRT) (TURN) (ACAP) (MODP) (TOOL) 3 


PHASE  DISTRIBUTION  OF  DEVELOPMENT  EFFORT  (FRAC  ) 

P 


MM  =  C (KEDSI >( (FRAC  ) 3/ (KEDSI ) / (MM  )3IEAF3 

NOM.P  P  NOM 

COMPUTER  TIME  =  (MM  ) (CHR/MM  ) 

DEV  DEV 
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IMPLEMENTATION 


INSTALLATION  =  (INST) (MM  ) 

DEV 


TRAINING 


=  (TRAIN) (MM  ) 
DEV 


ANNUAL  MAINTENANCE  PERSON-MONTH  (MM  ) 

AM 


MM  =  (ACT) (MM  ) (EAF  ) 
AM  NOM  M 


MAINTENANCE  EFFORT  ADJUSTMENT  FACTOR  (EAF  ) 

M 


EAF  =  C (PCAP  > (VEXP  ) (LEXP  ) (CPLX  ) (RELY  ) (AEXP  ) 3 
-Ci  M  M  M  M  M  M 


MAINTENANCE  ACTIVITY  APPORTIONMENTS 


REPAIRS  =  45. 3/ 100 (MM  ) 

AM 

UPDATES  =  54. 7/ 100 (MM  ) 

AM 

NOMINAL  DEVELOPMENT  TIME  (TD) 


O.  38 


ORGANIC  TD 

2.  5 (MM  ) 

DEV 

0 . 35 

SEMIDETACHED  TD  = 

2.  5 (MM  ) 

DEV 

0.  32 

EMBEDDED  TD 

2. 5 (MM  > 

DEV 
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NOMINAL  IMPLEMENTATION  TIME  <TI) 


1.05 

ORGANIC  TI 

3.2  <MM  > 

DEV 

1.12 

SEMIDETACHED  TI  = 

3 . 0 ( MM  ) 

DEV 

1.20 

EMBEDDED  TI 

2 . 8 ( MM  > 

DEV 

5.5  Help  Screens 

The  following  HELP  screens  will  be  developed  for  interac¬ 
tive  inputting: 

1)  MODE 

This  screen  will  provide  help  in  determining  the  expected 
software  development  mode.  It  will  appear  on  the  screen  as 
f ol lows: 


NODE  =  Softnare  Development  Node. 

NODE  CHARACTERISTICS  EXAMPLES  INPUT 

0R6ANIC  Less  than  50KDSI  Scientific  Nodels  0R6N 

Hinieal  Innovation  Business  Nodels 

Loosely  Structured  Faeiliar  OS/Coapilers 

SEMIDETACHED  Less  than  300KDSI  Training  Simulators  SENI 

Noderate  Innovation  Transaction  Processors 

Moderately  Structured  Me*  OS/DBNS 

EMBEDDED  All  sizes  Complex  Simulators  ENBD 

Innovative  Real  Time  Processors 

Tightly  Structured  Command  and  Control 


2)  CPI 


This  screen  will  provide  help  in  determining  the  Conver¬ 
sion  Planning  Increment  to  cover  the  added  costs  of  feasibil¬ 
ity  analysis  and  planning  of  existing  software  for  a  new 
application  not  included  in  adaptation  estimates.  It  will 
appear  as  follows: 

CPI  -  Conversion  Planning  Increment 
LEVEL  OF  CONVERSION  ANALYSIS  AND  PLANNING 
None 

Si apt e  schedule,  acceptance  plan 
Detailed  schedule,  test,  acceptance  plans 
Basic  analysis  of  inventory  of  code,  data 
Detailed  inventory  plus  basic  documentation 
Detailed  inventory  plus  detailed  documentation 

3)  DM 

This  screen  will  provide  help  in  determining  the  percent 
of  the  adapted  software's  design  which  will  be  modified  in 
order  to  adapt  it  to  the  new  objectives  and  environment.  It 
will  appear  as  follows: 


INPUT 

0 

1 

2 

3 

4 
3 


C  DR  *  Percent  Design  Modified 

LEVEL  OF  ADAPTED  DESIGN  MODIFICATION 
None 

Change  to  accommodate  different  doctrine 
Change  to  accommodate  overlay  structure 
Change  to  overlay  structure,  analog;,  logic 
Different  formats,  protocols,  equipment 


INPUT 

0 

5 

10 

IS 

50 


4)  CM 
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This  screen  will  provide  help  in  determining  the  percent¬ 
age  of  adapted  software’s  code  which  will  be  modified  in  order 
to  adapt  it  to  new  objectives  and  environment.  It  will  appear 
as  follows: 


5)  IM 

This  screen  will  provide  help  in  determining  the  percent¬ 
age  of  effort  required  to  integrate  adapted  software  into  an 
overall  product,  as  compared  to  the  normal  amount  of  integra¬ 
tion  effort  for  software  of  comparable  size.  It  will  appear 
as  follows: 


6)  COMP 


This  screen  will  provide  help  in  determining  an  estimate 
of  computer  run  time  hours  required  to  support  a  man-month  of 
software  development  activity.  It  will  appear  as  follows: 


C  COUP  =  Computer  Hours/Developaent  Nan -Month 

PROJECT  CHARACTERISTIC 

INPUT 

Saall-aediua  tiaeshare  application,  Naxi 

0.2 

Saall-aediua  tiaeshare  application.  Nidi 

0.6 

Saall-aediua  tiaeshare  application,  Nini 

1.5 

Large-very  large  or  hatch  application,  Naxi 

3.0 

Real-tiae  hardware-software  product,  Naxi 

3.0 

Real-tiae  hardware-software  product,  Nidi 

6.0 

Real-tiae  hardware-software  product,  Mini 

9.0 

Real-tiae  hardware-software  product,  Micro 

18.0 

J 

7)  CPLX 


This  screen  will  provide  help  in  determining  an  effort 
multiplier  based  on  complexity  of  the  software  program  to  be 
developed.  It  will  appear  as  follows: 


f  CPLX  =  Complexity 


TYPE  OF  NODULE  INPUT 

Straightline  code;  Siaple  read,  write  stateaents;  Siaple  arrays  .70 

Straight  forward  nesting!  Noderate  level  expressions;  .85 

Single  Tile  subsetting 

Siaple  nesting,  interaodule  control;  Standard  aath  operations;  1.00 
Error  processing,  siaple  edits 

Highly  nested  operators  with  coapound  predicates,  nuaerical  1.15 
analysis;  Special  purpose  subroutines,  coaplex  data  restructuring 

Recursive  coding,  fixed-priority  interrupt;  Diagnosis,  1.30 

servicing,  aasking;  paraaeter-driven  files 

Multiple  scheduling,  dynaaicallf  priorities,  aicrocode- level  1.65 

control;  Device  tiaing-dependent  coding;  Highly  coupled  structures 

V _  _ _ ) 
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8)  RELY 

This  screen  will  provide  help  in  determining  the  relative 
effort  of  software  development  required  for  software  reliabil¬ 
ity  for  a  given  number  of  delivered  source  instructions.  It 
will  appear  as  follows: 


RELY  *  Software  Reliability 


EFFECT  OF  SOFTWARE  FAILURE  EXAMPLE 


Inconvenience  of  fix 


Easily-recoverable  loss 
to  users. 

Moderate  loss!  Recover 
with  penalty 

Major  loss  or  inconvenience 


Loss  of  huaan  life. 


Deionstration  prototype! 
Feasibility-phase  simulation 

Planning  aodel  or 
forecasting  aodel. 

Manageaent  inforaation  or 
inventory  control  systeas 

Accounting  systeas  t  power 
distribution  systeas 

Military  coaaand  and  control 
systeas 


9)  PCAP 


This  screen  will  provide  help  in  determining  the  esti¬ 
mated  relative  software  production  based  on  programmer 
capability.  It  will  appear  as  follows: 

^  PCAP  =  Prograaaer  Capability  <Teaa) 

RELATIVE  EFFICIENCY  AND  THOROUGHNESS  INPUT  I 

Very  Low  151  1.42 


Noainal 


Very  High 


10)  VEXP 


This  screen  will  provide  help  in  determining  the  esti¬ 
mated  relative  so-ftware  production  based  on  project  team’s 
virtual  machine  experience.  It  will  appear  as  follows: 


VEXP  *  Virtual  Machine  Experience 
AVERAGE  EXPERIENCE 
<  1  Honth 
4  Months 
1  Year 
>  J  Years 

V _ 

11)  LEXP 

This  screen  will  provide  help  in  determining  the*  esti¬ 
mated  relative  software  production  based  on  the  level  of 
programming  language  experience  of  the  project  team  developing 
the  software  module.  It  will  appear  as  follows: 


INPUT 

1.21 

1.10 

1.00 

.90 


r 


LEXP  1  Progressing  Language  Experience 


AVERAGE  EXPERIENCE 
<  1  Month 


4  Nonths 
1  Year 


INPUT 

1.14 

1.07 

1.00 


.95 


J 


)  3  Years 


12)  AEXP 


This  screen  will  provide  help  in  determining  the  level  of 
applications  experience  o-f  the  project  team  developing  the 
proposed  software.  It  will  appear  as  follows: 


13)  INST 

This  screen  will  provide'  help  in  determining  the 
estimated  percent  of  development  effort  required  for  software 
program  installation.  It  will  appear  on  the  screen  as 
f ol 1 ows: 


INST  =  Installation  Effort 

TYPE  S0FHARE  INPUT 

Application  progran  on  existing  general  purpose  conputer  .2 

Application  progran  on  different  general-purpose  conputer  .8 

Process  control  prograa  on  nen  conputer  3 

Hunan-nachine  systee  13 


14)  TRAIN 


This  screen  will  provide  help  in  determining  the  esti¬ 
mated  percent  of  develpment  effort  required  for  newly  install¬ 
ed  software  programs.  It  will  appear  on  the  screen  as  follows 


^  TRAIN  *  Training  Effort 

TYPE  SOFTWARE  INPUT 

Application  p rograa  on  existing  general-purpose  computer  1 

Application  prograa  on  different  general-purpose  coaputer  3 

Process  control  proqrao  on  neu  coaputer  4 

Huaan-aachine  systea  6 

l 


15)  ACT 

This  screen  will  provide  help  in  determining  the  fraction 
of  source  instructions  which  undergo  change  during  a  typical 
year  either  through  additions  or  modifications.  It  will  ap¬ 
pear  as  follows: 


ACT  *  Annual  Change  Traffic 

TYPE  OF  SOFTWARE 

Non  real-tiae  input/output 

Hatheaatical  and  logical  operations 

File,  data  base  aanipulation,  real-tiae  control 

Coaplex  process  control  systea 

Real-tiae  coaaand  and  control 


INPUT 


.01 


.05 


.20 


.40 


16)  TIME 

This  screen  will  provide  help  in  determining  the  added 
effort  required  -for  a  given  number  of  instructions  based  on 
execution  time  required.  It  will  appear  as  follows: 


17)  STOR 

This  screen  will  provi&e  help  in  determining  the  esti¬ 
mated  added  effort  required  for  a  given  number  of  instructions 
based  on  main  storage  usage.  It  will  appear  as  follows: 


'  STOR  =  Main  Storage  Required 

REQUIRED  HEHORY 

IHPUT 

Noainal  <  SOI 

1.00 

High  701 

1.06 

Very  High  851 

1.21 

Eitra  High  951 

1.56 

18)  DATA 


This  screen  will  help  in  determining  the  increased  effort 
for  development  of  the  data  base  required  to  support  the 
proposed  program.  It  will  appear  as  follows: 


19)  VIRT 

This  screen  wi 1 1  provide  help  in  determining  an  estimate 
of  the  effect  of  virtual  machine  volatility  impact  on  the 
effort  required  to  develop  a  given  number  of  delivered  source 
instructions.  It  will  appear  as  follows: 


VIRT  *  Virtual  Machine  Volatility 


MAJOR  CHANGE 

MINOR  CHAN6E 

INPUT 

12  Months 

1  Month 

.87 

4  Months 

2  Meets 

1.00 

2  Months 

1  Meet 

1.15 

2  Meets 


2  Days 


1.30 


20)  TURN 


This  screen  will  provide  help  in  determining  the  impact 
on  development  effort  of  estimated  turn-around  time  for  pro¬ 
gram  decks.  It  will  appear  as  follows: 


21)  ACAP 

This  screen  will  provide  help  in  determining  the  esti¬ 
mated  impact  of  the  software  analysts  capability  on  the  effort 
required  to  develop  a  given  number  of  delivered  source 


instructions.  It  will  appear  as  follows: 


22)  MODP 


This  screen  will  provide  help  in  determining  the  esti 
mated  impact  of  modern  programming  practices  on  software  de 
velopment  effort.  It  will  appear  as  follows: 


23)  TOOL 

This  screen  will  provide  help  in  determining  the  esti 
mated  impact  of  software  tools  to  be  used  on  the  development 
It  will  appear  as  follows: 


^  TOOL  =  Software  Tools 

TYPE  SUPPORT 

INPUT 

Basis  eicroprocessor  tools 

1.24 

Basic  aini  tools 

1.10 

Strong  aini,  Basic  aaxi  tools 

1.00 

Strong  aaxi,  Stoneaan  HAPSE  tools 

.91 

Advanced  aaxi,  Stoneaan  APSE  tools 

V 

.83 

_ , 
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INTERACTIVE  COMPUTER  PROGRAM 


6. 1  Structure 

An  interactive  computer  program  will  be  structured  to 
allow  rapid  extension  and  modification  of  C3I  software  break¬ 
downs  to  three  levels  of  detail,  CPCI,  CPC,  and  module  level. 
See  figure  6-1.  The  structure  will  provide  fast  reaction 
cost  estimates  for  software  designs.  The  user  will  be  aided 
throughout  the  entire  execution  of  the  estimate  by  "HELP" 
screens  which  detail  data  input  definitions,  the  availability 
of  default  and  historical  data  bases  from  which  information 
can  be  extracted,  and  the  verification  that  data  entered  lies 
within  pre-defined  constraints. 

The  programs  will  be  written  in  a  higher  order  language 
applicable  to  either  a  personal  or  time-sharing  computer  al¬ 
lowing  for  portability  across  a  whole  line  of  computers.  The 
design  will  be  modular  in  style  for  ease  in  maintainability. 

Six  groups  of  programs  should  be  developed: 
o  Executive  programs 
o  Library  modules 
o  C3I  Breakdown  structures 
o  Cost  Element  Estimating  modules 
o  "HELP"  Screen  Generation  modules 
o  Report  Generators 

The  executive  program  wll  be  the  driver  which  sequences 
all  the  modules  into  the  flow  required  to  provide  the  data  for 
the  generation  of  specific  output  reports. 


HELP 

SCREENS 


6ENERIC  S/M 
DESIGN 
DEFAULT 
DATA  FILES 


ENVIRONMENT 

DATA 

FILE 


-  NODULES 

-  CPCs 

-  CPCIs 


USER  INPUTS 

EXECUTIVE 

HISTORICAL 

-  MODULES 

INTERACTIVE 

PR06RANS 

DATA 

-  CPCs 

DIALOGUE 

k 

FILES 

-  CPCIs 

SCHEDULE 
I-  LABOR  RATES 
COMPUTER  RATES 


\ 

N 

MODULE  LEVEL  S/H 
LCC  SUMMARY 

\ 

CPC  LEVEL  S/M 

LCC  SUMMARY 

_ i 

CPCI  LEVEL  S/M 

LCC  SUMMARY 

— 

Figure  6-1.  Estimating  System  Model  Structure 


The  library  modules  will  contain  all  the  routines  which 
are  common  to  the  three  levels  o-f  C3I  software  breakdowns. 

The  C3I  software  breakdown  structures  will  be  available 
from  a  set  of  historical  default  data  bases.  Judgements  for  a 
given  input  will  be  made  from  review  of  this  data,  i.e.,  from 
past  size  association.  The  user  will  be  able  to  take  advan¬ 
tage  of  the  existing  structures,  make  minor  modifications,  or 
create  an  entirely  new  breakdown  or  data  set. 

The  cost  element  estimating  modules  will  be  mutually 
exclusive  programs  which  develop  the  cost  estimates  for  each 
level,  i.e.,  given  the  inputs,  the  respective  estimation  equa¬ 


tions  will  be  computed  and  the  desired  reports  generated. 


Although  these  programs  will  be  mutually  exclusive,  the  user 
will  have  the  capability  to  initially  request  the  execution  of 
a  lower  level  program,  e.g.,  module  estimate,  and  subsequent¬ 
ly  request  the  next  level.  As  the  inputs  change  from  the 
lower  levels,  the  cost  summaries  will  be  correlated  to  change 
at  each  level  of  system  structure. 

The  "HELP”  Screen  generation  modules  will  be  interactive 
aids  displayed  to  assist  in  input  defintions  and  data  re¬ 
quirements.  Each  input  parameter  will  have  its  unique  dis¬ 
play. 

The  report  generators  will  be  a  series  of  modules  which 
output  data  to  any  level  of  detail  requested  by  the  user. 

6.2  Logic 

The  model  will  compute  and  summarize  software  costs  over 
the  life  cycle  of  a  module,  computer  program  component,  or 
computer  program  configuration  item.  A  default  generic  data 
set  will  be  established  for  each  level  based  on  historical 
data.  This  will  allow  the  user  to  establish  a  unique  breakdown 
for  each  phase  required  and  to  generate  a  tailored  structure. 
Once  the  data  set  has  been  created,  it  can  be  modified  at  any 
time  during  execution  of  the  model.  Given  a  data  set,  the 
cost  estimating  modules  can  be  executed  to  generate  output 
which  display  the  cost  estimates  in  a  wide  variety  of  reports 
ranging  from  top  level  LCC  summary  to  lower  detail.  Figure  6-2 
depicts  the  model  flow  logic.  All  inputs  are  prefaced  with 
user  friendly  prompts  and  validated  to  be  within  certain 

Help  screens  are  available  at  all 


predefined  constraints. 


evels  tD  assist  the  user 


Figure  6-2.  Model  Logic 

Functions 

Figure  6-3  presents  a  generalized  computer  module  break- 


Several  modules  may  be  represented  by  a  single  block  in 


the  figure.  The  function  of  each  module  in  the  program  is 
summarized  as  follows: 

REQUIRED  PROGRAMS 


DATA  BASE  CREATE/ 

COST  ESTIMATE 

- -4. . 

SUPPORT 

UPDATE  COMPONENT 

COMPONENT 

COMPONENT 

FILE  RETREIVAL 

_ 

INPUT  RTN 
WITH  USER 
FRIENDLY  DIALOGUE 

DATA  VALIDATION 


UPDATE  PROCEDURE 


-  OUTPUT  RTN  TO 
LIST  CONTENTS  OF  BASE 

FILE  STORAGE  RTN 


SELECTION  RTN 

INPUT  RTN  FOR 
COMMON  DISK 


INPUT  RTNS  FOR 
PECULIAR  DATA 

—  CER  RTNS  FOR 
EACH  LEVEL 


HELP  SCREEN  M6HT 

FILE  RETRIEVAL 
MGMT 


FILE  STORAGE 
1  M6MT _ 

— (FILE  LIST 
RTN 


-  SUMMARY  t  TIERING 

OF  BASE  OF  COSTS 

!TN~1  — -[REPORT  GENERATORS) 

— -[help  screens 

Figure  6—3.  Module  Breakdown 


a)  Eliecuti_ve 

initialize  default  data 

—  read  all  common  data  files  from  disL 

—  determine  which  function  to  perform  user  request: 

o  create/update  data  set  for  a  particular 
task 

o  generate  reports,  given  an  emstinq  data  set 
°  create/update/ 1 1 st  libraries  of  default, 
historical  and  environmental  data 


77 


-  determine  which  level  (module,  CPC,  CPCI)  is  to 
be  executed  (user  request) 

-  bring  model  into  execution 

upon  termination  of  execution,  replace  data  files 
on  disk,  etc. 

Envi CSQffllQt  Data  Set 

-  create/update/ 1 i st  contents  of  library  file 

-  interactive  dialogue  and  input  data  validation 

-  display  "HELP"  screen  for  user  assistance 

-  restore  created/updated  file  to  disk 
Data  Base  Sel_ect j_gn/L)pdate 

-  display  menu  of  bases  available 

-  retrieve  user  selected  data  base  from  disk 

-  update/edit  base  via  interactive  dialogue  and 
validated  data  inputs. 

-  display  "HELP"  screens  upon  user  request 

-  replace  new /up dated  data  set /base  on  disk 
dli.E  Screens 

-  develop  a  single  screen  for  each  input 

-  upon  user  request,  display  data  defaults  of 
current  input  item 

-  upon  user  request,  erase  help  screen  from  display 
Cost  Estimation 

read  in  selected  data  base  file 
read  in  environmental  data  file 

make  adjustments  to  data  in  order  to  normalise  to 


one  base 


-  calculate  cost  estimating  equations 

-  call  report  generator  to  generate  output  reports 

-  summarize  outputs  to  next  level  of  software 
hi erarchy 

-  save  all  necessary  files  on  disk 
f )  Resect  G§Q§?r  atgr 

-  request  report  selection  (user  request) 

-  generate  reports 

6.4  Application 

The  interactive  computer  program  will  consist  of  compu¬ 
terized  models  and  stored  libraries  of  datasets.  The  programs 
to  be  developed  are  the  following:  a  main  calling  program,  an 
environment  data  set  program,  a  CPCI  data  set  program,  a  CPC 
data  set  program,  and  a  module  data  set  program.  The  dataset 
programs  will  contain  the  COCOMO  equations. 

The  main  calling  program  will  be  a  simple  routine  that 
allows  the  user  to  load  the  four  models  which  make  up  the 
overall  software  cost  estimating  model. 

The  environment  data  set  program  program  will  allow  the 
user  to  create  a  library  of  data  files  which  summarize  the 
schedule  and  cost  factors  which  affect  the  estimated  life 
cycle  cost  of  the  CPCIs,  CPCs,  and  modules.  A  large  number  of 
individual  environment  data  sets  can  be  developed  and  stored. 
Any  one  of  these  data  sets  can  be  "marked"  for  use  by  the 
CPCI,  CPC,  and  module  programs  for  a  particular  cost  estimate. 

The  CPCI  data  set  program  allows  the  user  to  create  a 
library  of  CPCI  designs  and  store  the  life  cycle  cost  of  each. 
Any  one  of  those  data  sets  can  be  "marked".  Each  design 
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consists  o-f  a  set  of  CF'CI-level  parameters  and  vectors  which 
contain  the  number  of  appearances  in  the  CF’CI  of  each  marked 
CPC  in  the  CPC  library.  Any  number  o-f  individual  CF'CI  data 
sets  can  be  stored. 

The  CPC  data  set  program  allows  the  user  to  create  a 
library  of  computer  program  component  designs  and  store  the 
life  cycle  cost  of  each.  The  cost  results  are  stored  in 
output  data  files  which  are  read  by  the  CF'CI  model.  Each 
design  consists  of  a  set  of  CF'C-level  parameters  and  a  vector 
which  contains  the  number  of  appearances  in  this  CPC  of  each 
marked  module  in  the  module  library. 

The  module  data  set  program  allows  the  user  to  create  a 
library  of  module  designs,  each  consisting  of  a  set  of  func¬ 
tional  module  parameters,  and  store  the  life  cycle  cost  of 
each  alternative.  Cost  results  are  stored  for  each  module  in 
output  data  files  which  are  read  by  the  CPC  model. 

Figure  6-4  summarizes  the  relationships  that  exist 
between  the  models  and  datasets  that  make  up  the  software  cost 
estimating  system. 
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this  analysis,  and  a  parameter  summary  and  associated  life 
cycle  costs  from  stored  similar  datasets,  judgments  can  be 
made  on  the  required  inputs  -for  a  new  design. 

An  example  of  the  functional  analysis  required  to  build  a 
baseline  design  is  illustrated  in  figures  7-1,  and  7-2  and 
table  7-1  for  a  portion  of  a  generic  Air  Defense  system’s 
computer  program  requirements  .  Figure  7-1  shows  the  overall 
generic  work  breakdown  structure  and  associated  software 
breakdown.  The  required  computer  programs  to  control  the 
system  are  those  that  control  the  acquisition  and  tracking  of 
targets,  make  engagement  determinations,  and  guide  the  inter¬ 
ceptor  to  target.  Eight  CF'CIs  are  identified: 

1 )  Search 

2)  Track 

•3)  Guidance 

4)  Engagement  Determination 

5)  Communication 

6)  Display 

7)  System  Utilities 

8)  System  Control 
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LEVEL  1 


DEFENSE  SYSTEM 


LEVEL  2  PRIME  MISSION  PRIME  MISSION  PRIME  MISSION  PRIME  MISSION 

EQUIPMENT  SOFTNARE  LOGISTICS  TRAINING 

' 


Figure  7-1.  So-ftware  Breakdown  Structure  For  an  Air  De-fense  System 
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Table  7-1  shows  the  functions  performed  by  the  dEARCH 


CPC  I. 


Table  7-1.  Search  Modules 


Size 

Type 

CPC 

Search  Beat  Alar*  Response 

3615 

3 

2 

Beat  Interference  and  Detection  Interpreter 

2492 

3/4 

3 

Multiple  Target  Correlation  Filter 

1050 

3 

4 

Frequency  Selection 

41 

4 

4 

Search  Roster  Hanageaent 

136 

4 

1 

Target  Range  Acquisition 

119 

3/4 

5 

Angle  Filter 

509 

3 

4/5 

Target  Validation 

442 

3/4 

4 

Bea*  Record  Angle  Generator 

2076 

3 

4/5 

Alternate  Search  File  Processing 

1401 

3/4 

1 

The  grouping  of  these  functions  into  computer  programming 
control  packages  is  shown  in  figure  7-2.  The  first  function 
is  "search  beam  alarm  response".  This  function  is  estimated 
to  require  a  module  of  3615  delivered  source  instructions. 
The  module  is  a  generic  type  3,  or  Algorithmic,  and  it  is 
logically  grouped  into  the  work  package  for  CPC  2,  "Alarm 
Detection".  The  same  approach  is  taken  for  all  the  functions 
to  be  performed  by  the  CPC I. 


Figure  7  2.  Allocation  of  the  Search  Modules  into  CPCs 

In  some  cases  the  module  of  code  to  be  developed  -fits 
more  than  one  generic  category.  For  instance,  the  second 
module  "Beam  Interference  and  Detection  Interpreter "  is  cate¬ 
gorized  as  both  an  algorithmic  module  and  a  logic  control 
module.  In  other  cases,  one  generic  module  is  used  in  more 
that  one  CPC.  For  instance,  the  "Angle  Filter"  module  is  used 
in  both  the  Target  Validation  CPC  and  the  Target  Acquisition 
CPC.  Figure  7-3  through  7-9  show  the  remaining  CPCI  alloca¬ 
tions  to  CPCs,  and  tables  7-2  through  7-8  show  the  remaining 
module  sizing,  typing,  and  CPC  assignments. 

The  development  of  libraries  of  generic  C3I  CPCIs  is 
passible.  What  is  required  is  a  functional  analysis  and  model 
calibration  of  existing  systems. 
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Table  7-2  Track  Modules 


LEVEL  4 


LEVEL  5 


Size 

Type 

CPC 

Target  Update 

526 

3 

1 

Range  Filter  Saoothing 

436 

3 

3 

Target  lleasureient  Updating 

66 

3 

3 

Track  Initiation 

314 

4 

2 

Track  Dispatcher 

1545 

4 

1/2 

Track  Return 

588 

3/4 

1/2 

Foraation  Discriaination 

1755 

3/4 

5 

Target  Initialization 

333 

4 

1 

Range  Angle  Update 

12? 

3 

3 

Request  Net*  Radar  Action 

473 

3/4 

3 

Range  Acquisition  Separation 

3120 

3/4 

5 

Separation  Algarithas 

525 

3 

5 

No  Target  Alara  Processing 

980 

3/4 

4 

Triangulation  Assist  Request 

717 

4 

2/4 

Target  Coaaunication  Request 

1005 

4 

1/2/4/5 

Drop  Track 

147 

4 

5 

Scale  Factor  *  Radar  Range  Cell  Weighting 

185 

3 

3 

Target  No.  Alara  Processing 

2101 

3/4 

4 

Target  Separation 

2361 

3/4 

5 

Figure  7-3.  Allocation  of  the  Track  Computer  Program 
Requirement  into  CPCs 


Table  7-3.  Guidance  Modules 


Size 

Type 

CPC 

Calibration  Response  Processor 

967 

3/4 

4 

Dounlink  Processor 

1829 

3/4 

3/4 

Fuze  Algoritha 

200 

3/4 

5 

Missile  Acquisition  Radar  Message  Filter 

365 

3 

2 

6uidance  and  Control 

1859 

4 

3/4 

Missile  vs.  Target  Filters 

3156 

3 

4 

Guidance  Loop  Error 

228 

3 

4 

Guidance  initialization 

282 

3/4 

2 

Seeker  Coaaand  Routine 

234 

4 

4 

Missile  Link  Antenna  Selection 

496 

4 

1/2 

Nidcourse  Guidance  Phase  1 

375 

3/4 

3 

Nidcourse  Guidance  Phase  2 

219 

3/4 

3 

Nidcourse  Coaputations 

98 

3 

3/4 

Boresight  Nulling  Processor 

68 

3 

4 

Prelaunch  and  Initial  Turn  Calibration 

2307 

3 

1 

Terainal  Guidance  Phase  2 

438 

3/4 

4 

Terainal  Guidance  Phase  3 

211 

3/4 

4 

Transformation  Matrix  Algoritha 

412 

3 

3/4 

Track  Response  Processor 

3130 

3/4 

4 

Terainal  Guidance  Phase  1 

1549 

3/4 

4 

Missile  Message  Foraatter 

823 

4 

2 

Auto  Pilot 

400 

3 

3/4 

6iabal  liaitinq  Algoritha 

82 

22,000 

3 

3/4 

LEVEL  4 


LEVEL  5 

CPC  1 

CPC  2 

PRELAUNCH  t, 

MISSILE 

INITIAL  TURN 

ACQUISITION 

Figure  7-4.  Allocation  o-f 
Requirement 


the  Guidance  Computer  Program 
into  CPCs 
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Table  7-4.  Engagement  Determination  Modules 


LEVEL  4 


LEVEL 


Figure  7 


First  Target  Evaluator 

Size 

48 

Type 

4 

CPC 

3 

Engagement  Initiation 

150 

4 

4 

Launch  Now  Intercept  Point  Calculation 

387 

3 

3 

Time  Till  First  Launch  Calculation 

356 

3 

3 

Target  Threat  Calculation 

425 

3 

3 

Target  Position  Update 

152 

3 

3 

Target  ID/Engage«ent  Evaluation 

2970 

4 

1/2/3 

Target/Volume  Correlation 

322 

3 

1 

IFF  Command  and  Test  Action  Schedule 

866 

4 

2 

IFF  Response  Processor 

679 

3/4 

2 

IFF  Update  and  Time  of  Day  Correlation 

353 

3/4 

2 

Engagement  Queue  Nanageient 

Add  Target  to  Queue 

309 

4 

3 

Delete  Target  from  Queue 

90 

4 

3 

Start  Queue  Entry 

45 

4 

3 

Queue  Keyword  Formation 

83 

4 

3 

Return  Queue  Entry 

47 

4 

3 

Update/Establish  Queue 

632 

4 

3 

Neapon  Assignment 

1887 

3/4 

4 

Engagement  Termination 

515 

4 

4 

Kill  Assessment 

482 

3/4 

4 

Hold  Fire  Coaaand/Receipt 

133 

4 

4  ■ 

Cease  Fire  Coaaand/Receipt 

112 

4 

4 

Identity  Change  Hanager 

595 

4 

2 

Target  Status 

319 

4 

2 

Guidance  Time  Slot  Determination 

377 

3/4 

4 

Process  for  Engagement 

172 

4 

3 

5.  Allocation  o-f  the  Engagement  Determination 
Computer  Program  Requirement  into  CPCs 
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Table  7-5.  Communications  Modules 


Size 

Type 

CPC 

Output  Message  Generator 

4551 

2/3/4 

l 

Input  Message  Processor 

5660 

2/3/4 

2 

Message  Request  Sueuing 

461 

2/4 

1 

Source  Code  State  Filter 

70 

3 

2 

UHF  Antenna  Azieuth  Set-Up 

152 

4 

3 

Radio  Unit  Initialization  +  Status 

756 

2 

3 

Static  Data  Buffer  Transfer 

1144 

2/3 

1/2 

Figure  7-6.  Allocation  of  the  Communications  Computer 
Program  Requirement  into  CPCs 
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Table  7-6 


Display  Modules 


Size 

Type 

Target  fl-Scope  Presentation 

890 

3 

Display  Target  Syebol 

235 

4 

Keyboard  Input  Processor 

760 

2/4 

Keyboard  Input  Validator 

514 

4 

Operator  Target  Selection 

210 

2/4 

Situation  Display  Processor 

Static  Refresh 

618 

4 

Geographic  Refresh 

1097 

4 

Volatile  Refresh 

1685 

3/4 

Modifier  Refresh 

542 

4 

Target  Window  Cropping 

316 

3 

Tabular  Display  Processor 

Tabular  Skeleton  Refresh 

2162 

4 

Tabular  Input  Processor 

1848 

2/4 

Tabular  Cursor  Control 

1833 

4 

Display  Sitithch  Handler 

4125 

2/4 

Operator  Alert  Processing 

650 

4 

Operator  Alert  Acknouledgeeent 

461 

2 

Figure  7—7.  Allocation  o-f  the  Display  Computer 
Requirement  into  CPCs 
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LEVEL  4 


LEVEL  3 


Figure  7-8 


Table  7-7.  System  Control  Modules 

Size  Type 


Thread  Control  Data  Base  200 

Executive  Task  Hanageeent  11203 

Real  Tiae  Initialization  1418 

Suspend  Real  Tiae  190 

Rode  Control 

Equipment  Rode  Control  Processor  592 

Fire  Section  Node  Control  3038 

Radar  Overload  Processor  238 

Invalid  Radar  Response  Processor  178 

Systea  Honitor 

Radar  Operational  Assessaent  818 

High  Priority  Radar  State  Foraatter  125 

High  Priority  Radar  State  Scheduler  130 

High  Priority  Radar  State  Response  Processor  1525 
Routine  Radar  State  Foraatter  203 

Routine  Radar  State  Scheduler  319 

Terainal  Guidance  Assessaent  3332 

Launcher  Group  Assessaent  198 

Coaaunication  Path  Assessaent  774 

Radar  Resource  Evaluation  188 

Coaputer  Equipaent  and  Peripheral  Honitor  772 

Hajor  Abort  Processor  247 

Launcher /Radar  Routine 

Reorient  Radar  Routine  144 

Reorient  Launcher  Routine  312 

Launcher  Eaplaceacnt  427 

Radar  Eaplaceaent  210 

Reorient  Geographic  Data  457 

Clutter  Nap  Update  3024 

Terrain  Hashing  4189 

Radar  Action  Nessaqe  Scheduler  1949 

Radar  Resource  Saturation  Alleviation  510 


5 

1 

3/4 

4 

4 

4 

4 

4 

4 

4 

3/4 

3/4 

4 

3/4 

3/4 

4 

3/4 

4 

4 

4 

3 

3 

2 

2 

3 

3/4 

3/4 

I 

1 


CPC 


1 

1 

2 

2 

2 

2 

2 

2 

3 

3 

3 

3 

3 

3 

3 

3 


.  Allocation  of  the  System  Control  Computer 
Program  Requirement  into  CPCs 


Table  7-8.  Utility  Routine* 


Size  Type  CPC 


Extended  Floating  Point  Tiee  Generator  33  3 

Trigonometric  Procedures  iiW  3 

ASIN,  ATAN,  COS,  SIN,  TAN,  LOG,  E1P 
Natrix  Hultiplicr  n  3 

Teletype  Inpat/Output  MG  2 

Tactical  Tape  Read  ♦  Nrite  M5  2 

Hard  Copy  Print  184  2 

Latitude/Longitude  to  UTH  Transformation  31A  3 


2 

1 

2 

3 

3 

3 

2 


» 


LEVEL  4 


LEVEL  3 


Figure  7-9.  Allocation  of  the  Utility  Computer  Program 
Requirement  into  CPCe 
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RAVC  plan*  and  executed  research,  de.veZopme.nt,  tut  and 
selected  acquisition  programs  in  support  oi  Command,  Control 
Communications  and  Intelligence.  (C3I)  activities.  Technical 
and  engineering  support  within  areas  oi  technical  competence 
u  provided  to  ESP  Program  OUice s  (POs)  and  other  ESP 
elements.  The  principal  technical  mission  areas  are 
communications,  electromagnetic  guidance  and  control,  sur- 
\  veulance  oi  ground  and  aerospace  objects,  intelligence  data 
1  collection  and  handling,  iniormation  system  technology, 

>  ionospheric  propagation,  solid  state  sciences,  microwave 
physics  and  electronic  reliability,  maintainability  and 
compatibility. 
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